Verification: a143cc29221c9be0

Mysql и php для чего они нужны

Mysql и php для чего они нужны

Особенности языка PHP

Эти особенности определяют то, как PHP выполняет задачи, общается с сайтами и приложениями и кто его может менять (спойлер — все).

PHP — скриптовый (сценарный) язык. На таких языках пишут сценарии или скрипты — программы, которые автоматизируют небольшие рутинные задачи. Иначе их попросту пришлось бы выполнять вручную.

Как работает PHP, объясняют на канале сообщества веб-разработчиков WebShakeRU

Зачем нужны скрипты 

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

Выполнение сценария также называют его интерпретацией, а сам PHP — интерпретатором.

Аналогия, которая поможет лучше представить работу интерпретатора:

Есть файл, где половина текста на русском, а половина — на английском. Задача — перевести весь текст на русский. Точно так же и обработчик смотрит .php файл, который состоит из HTML (русский) и php-кода (английский, его надо обрабатывать, «переводить»)

PHP — интерпретируемый язык. Раз PHP — интерпретатор, это даёт много плюсов:

  • не нужно освобождать выделенную память или закрывать файлы по окончании работы с ними — всю рутинную работу сделает интерпретатор;
  • отладка программ и обнаружение ошибок упрощаются — интерпретатор полностью контролирует этот процесс;
  • сервер не «зависает» при неправильной работе приложения.

PHP — серверный язык. Всё работа происходит на удалённом веб-сервере. Открываете сайт — на сервер посылается запрос, выполняет заданные действия, отдаёт результат и завершается.

Что такое веб-сервер

Веб-сервер — это и про железо, и про программное обеспечение.

  • с точки зрения железа, это компьютер, который хранит ресурсы сайта (HTML-документы, CSS-стили, JavaScript-файлы) и доставляет их на устройство (браузер) пользователя. Обычно он подключен к интернету и доступен через доменное имя.
    Mozilla.org, youtube.com, shop.reg.ru — всё это доменные имена.
  • с точки зрения ПО, это HTTP-сервер — та часть ПО, которая понимает урлы (веб-адреса) и HTTP — протокол, который использует ваш браузер для просмотра веб-страниц.

Когда браузеру нужен файл, размещённый на веб-сервере, он запрашивает его через HTTP. Когда запрос достигает веб-сервера (железо), сервер HTTP (ПО) передает запрашиваемый документ обратно, тоже через HTTP. HTTP-ответ, как правило, содержит в себе HTML-страницу, изображение или обычный файл любого формата.

Это значит то, что на устройстве язык может быть вообще не установлен. Компьютер, ноутбук, смартфон могут PHP не понимать и быть c ним совершенно не знакомы. А сайт или приложение при этом запускается и стабильно работает.

Браузер тоже значения не имеет — программа на PHP успешно функционирует с любого.

Схема работы веб-сервера от сайта Lectureswww.readthedocs.io

Схема работы веб-сервера от сайта Lectureswww.readthedocs.io

PHP — язык с динамической типизацией. Это значит, что типы переменных определяются во время выполнения программы, разные типы можно использовать вместе, а неявные преобразования выполняются автоматически.

Статистическая vs динамическая типизация 

Языки программирования бывают со статической и динамической типизацией. 

  • статическая — переменная определена жёстко и не может быть изменена. Переменная или параметр будут принимать, а функция — возвращать значения только этого типа и никак иначе.  
  • динамическая — переменная не определена и может быть одновременно числом, строкой, массивом, объектом — чем угодно. Одной переменной можно присвоить число, затем массив и объект — и язык программирования это разрешит.

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

Ежедневные советы от диджитал-наставника Checkroi прямо в твоем телеграме!

Подписывайся на канал
Подписаться

Зачем придумали PHP

PHP изобрёл в 1994 году датский программист Расмус Лердорф. Тогда это был ещё не полноценный язык программирования, а всего лишь набор скриптов, который позволил Лердорфу сделать первое онлайн-резюме в виде HTML-страницы.

PHP расшифровывается как Personal Home Page — и отсылает к тому, чем язык был изначально — инструментом для разработки персональных веб-страниц

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

Сейчас PHP поддерживает компания Zend Technologies: в 1997 году она выпустила третью версию языка и активно развивают его до сих пор.

В итоге проект разросся до такой степени, что получил собственный синтаксис, много новых функций и признание в среде разработчиков.

Эволюция версий

Прежде чем стать одним из самых популярных языков программирования, PHP прошёл долгий путь. Проследим, как он изменился от первой версии к последней.

PHP 1.0-2.0 — 1994. Ранние версии были «сырыми». Первая и вторая модификации обладали базовой функциональностью сегодняшнего PHP. Она включала в себя переменные в стиле Perl — языка для работы с текстом, который и лёг в основу PHP, автоматическую интерпретацию форм, когда по приходу формы язык автоматически создаёт переменные, и возможность встраиваться в HTML-код.

Синтаксис имел много общего с Perl, хотя и был намного проще.

Второй версией PHP, которая получила название PHP/FI 2.0, пользовались 50 тысяч доменов — около 1% всех доменов в интернете

PHP 3.0 — 1997. Третья версия, по сравнению с предыдущими, шагнула далеко вперёд, и определила облик PHP, сделав язык таким, каким мы его знаем.

Израильские программисты Зеев Сураски и Энди Гутманс, которые тогда присоединились к проекту, решили переписать код заново, потому что PHP/FI 2.0 был очень ограниченным.

Одна из сильнейших сторон PHP 3.0 — возможность расширения ядра, которая привлекла к языку много сторонних разработчиков, желающих добавить в PHP свои модули. Это и стало ключом к успеху.

К концу 1998 года количество пользователей PHP исчислялось десятками тысяч. Третья версия уже заняла заняла 10% веб-серверов интернета, включая тех, что находились под управлением Windows 95, 98, NT и Macintosh. Её установили уже на семи тысячах доменов

PHP 4.0 — 1998. Переработка ядра — основная задача, которую поставили перед собой разработчики после выхода PHP 3.0. Эффективность приложений, написанных на PHP, была далека от идеала — нужно было что-то с этим делать. Новый движок Zend Engine решил проблему и значительно увеличил производительность PHP.

PHP 5.0 — 2004. Пятая версия получила обновлённое ядро — Zend Engine 2 и переработанные функции объектно-ориентированного программирования, которые стали во многом схожи с моделью, используемой в Java. А скорость кода повысилась на 10–20%.

PHP 6.0 — 2006. Шестую версию пропустили. В неё хотели встроить поддержку Unicode — стандарта кодирования, включающего в себя знаки почти всех письменных языков мира. Но релиз так и не состоялся. Вот почему:

«PHP 6 был амбициозным, но отстойным. Вот почему мы занялись PHP 7, в процессе пропустив шестую версию»

Vilson Duka, один из разработчиков

PHP 7.0 — 2015. Самая быстрая версия языка, работающая без статической типизации — она есть только в параметрах функции. Добавили новые операторы, возможность указывать тип возвращаемых из функции данных и контроль передаваемых типов для данных.

Как развивался PHP с момента возникновения: основные вехи. Видео от Питера Кокота

PHP продолжает развиваться. Сейчас тестируют восьмую версию, которую планирую выпустить в 2021-2022 годах.

Словарик

Модуль — законченный фрагмент программы, оформленный в виде отдельного файла с исходным кодом.

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

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

Чем хорош PHP

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

Простой синтаксис. По своей структуре PHP подобен С. Некоторые элементы перекочевали из Perl. А чтобы написать простейший скрипт, не понадобятся переменные и модули — достаточно операторов PHP.

Пример кода от онлайн-школы Skillbox

Пример кода от онлайн-школы Skillbox, выводящего надпись «Hello, World» на PHP, вставленного в HTML  

Богатая экосистема. PHP поддерживает много библиотек, фреймворков и баз данных.

YII, Laravel, Symfony, CodeIgniter, Phalcon, Slim, ZendFramework, CakePHP, Aura, Fat-free — далеко не полный список фреймворков, с которыми работает PHP

PHP поддерживает все известные базы данных — MySQL, PostgreSQL, SQLite, MS SQL, Oracle, dBase и др.

Список библиотек, которые поддерживают PHP

Список библиотек, которые поддерживают PHP

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

Подробная документация и много форумов, где можно найти решение определённых задач.

Если вы начинающий разработчик, вам подойдёт курс «PHP. Уровень 1» от GeekBrains, на котором вы изучите основы, синтаксис PHP и сможете сразу использовать полученные знания на практике

За что ругают PHP

Но не лишён PHP и существенных недостатков, за которые его принято критиковать.

Много багов. У гибкости и простоты языка есть и обратная сторона: написать чистый и качественный код сложно, допустить ошибку легко, а найти её почти нереально — это можно сделать только после запуска программы. Из-за этого у PHP очень много багов — намного больше, чем у остальных. Отсюда же и многочисленные уязвимости, через которые можно залезть в базы данных пользователей или что-то поломать на сайте.

Смешанный код. Исходный код — это смесь из двух языков, самого PHP и HTML, в который он встраивается. Это не проблема для маленьких отдельных фрагментов, но если речь идёт о большом многостраничном сайте, то разобраться, где вы сейчас находитесь, или отыскать необходимый кусок кода, довольно затруднительно.

Любые переменные в любом месте. В PHP можно просто поставить знак «$» в любой части кода. Конечно, это упрощает жизнь — берёте переменную и делаете с ней что хотите. Но потом проблемы неизбежны. Присвоили переменной не тот тип — и всё пошло не так. При этом всё работает, но неправильно. Можно голову сломать, думая, что не так, но так и не выяснить, в чём же дело. Другие языки, Java или C#, таких вольностей попросту не допускают и дают за них по рукам, требуя переменную объявлять заранее и сразу указывать тип.

Не работает в одиночку. От самого по себе PHP толку мало — чтобы пользоваться языком, нужно знать как минимум HTML, а лучше ещё и CSS. JavaScript тоже не помешает.

Отсутствие единообразия. Нет чёткой системы в названиях функций стандартной библиотеки.

В некоторых есть сокращения, в некоторых нет (call_user_func vs. create_function)

В некоторых есть подчёркивание, в некоторых нет (isset vs. is_null)

Обозначение str иногда бывает в названиях функций для работы со строками, иногда нет

Низкая скорость. PHP — не самый производительный язык. Его конкурент Javascript — быстрее.

Что делают на PHP

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

Вот что можно сделать на PHP:

  • Отдельные модули. PHP-код можно встраивать в HTML-страницы, а можно сохранить отдельным файлом. В этом случае мы получаем мини-модули, каждый из которых отвечает за что-то одно.

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

страницы портала Yahoo

Многие страницы портала Yahoo! созданы на PHP

  • CMS и движки сайтов. Модульные возможности PHP способствовали тому, что большинство современных систем управления контентом на сайтах написаны на PHP.

WordPress, Drupal, Joomla, MediaWiki, OpenCart, phpMyAdmin написаны на PHP

  • Форму для сбора данных и системы авторизации. Достаточно сообщить языку, что взять, из какого поля и по какому адресу отправить, а всё остальное интерпретатор сделает самостоятельно.

Facebook, страница регистрации

Facebook, страница регистрации. Вся серверная часть соцсети сделана на PHP

  • Динамические страницы. PHP-скрипт, который в зависимости от URL показывает разный контент.
  • Сессии и куки. Они нужны, чтобы хранить данные о пользователях при переходе между страницами. И это тоже механизм PHP, который можно реализовать через функции session_start().

Будущее PHP: что говорят эксперты

Вот что говорят о PHP программисты со стажем.

Илья Харченко, главный редактор The MASCC

«Есть умирающие языки, типа COBOL и FORTRAN. Есть традиционные языки, на которых работает, например, Microsoft — C# и JavaScript. Есть современные языки, пик возможностей которых ещё только ожидается Kotlin, Crystal, Rust и Swift.

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

Максим Жук, инженер-программист практики фронтенд компании «Рексофт»

«PHP остаётся одним из самых востребованных языков разработки серверной части веб-приложений. Хотя последние годы его начали теснить Node Js и Python, а со стороны решений для больших компаний пальма первенства у Java и .Net, но даже суммарно они занимают меньший рынок, чем PHP»

Эдуард Козлов, сооснователь BrainForce

«PHP продолжает находиться в топе языков, то немного опускаясь вниз, то опять поднимаясь вверх. Это классический язык, но он постоянно развивается: выходят новые версии языка, новые фреймворки и библиотеки. Если учесть распространение проектов на PHP в интернете, он будет развиваться и использоваться ещё много лет.

Рынок труда в 2020 году глобально изменился. Если раньше главным критерием наличия рабочего места был офис, то теперь из-за мировой пандемии даже компании с мировым именем стали использовать удалённую работу. Это открывает огромный потенциал для начинающих PHP-разработчиков. Если посмотреть вакансии на hh.ru, то они по-прежнему остаются в тренде!»

Подробнее о профессии PHP-программиста — читайте в этой статье

Стоит ли изучать PHP в 2021 году

Определённо стоит. PHP — популярный, простой в освоении язык для бэкенда, открывающий при этом большие возможности.

Будут ли веб-разработчики массово переходить на другие технологии — вопрос открытый. Сейчас, если вы приобретаете виртуальный хостинг, вам сразу включают интерпретатор PHP, потому что все его используют. А другие технологии типа Python или Node.js — нет, их нужно устанавливать отдельно.

Но ведь и веб — это не навсегда. Ещё лет 20, и понятие веб-сайта может устареть, потому что люди будут сидеть в приложениях и соцсетях.

Но ближайшие лет 5–10 спрос на язык точно будет. Он эволюционирует, скоро выйдет восьмая версия, да и отказаться от него не так-то просто — на PHP написано 80% интернета.

Так что можно спокойно изучать PHP и быть уверенным, что полученные навыки пригодятся. Особенно если вы хотите работать с «Вордпрессом», «Друпалом», «Джумлой» и другими известными системами управления сайтами. Они написаны на PHP, и все надстройки и дополнения — тоже.

Зачем нужны базы данных?

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

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

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

После сохранения данных вы можете к ним обращаться, выводить на страницы сайта, обрабатывать, редактировать, обновлять или же вовсе удалять. Хранить информацию можно еще в текстовых файлах на сервере, но такой вариант является не удобным, если вам часто нужно просматривать информацию или же редактировать её.

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

Как происходит работа с базами данных?

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

СУБД позволяет нам управлять базой данных. Например создать таблицу, добавить записи, обновить или отредактировать данные.

Мы изучим MySQL, что является системой или, другими словами, программой для управления базами данных. Для выполнения команд внутри базы данных используется язык запросов SQL.

Язык запросов SQL

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

SQL

. Язык достаточно прост в изучении и позволяет выполнять запросы к базе данных.

Через MySQL мы имеем доступ к базе данных. В ней у нас могут быть записи, а для управления записями мы будем использовать SQL запросы.

Язык SQL является универсальным языком, ведь вне зависимости от СУБД  и вне зависимости от серверного языка вы в любом случае используете те же SQL команды каждый раз.


PHP, конечно, жив, но Python пролезает в веб: Максим Шамаев о состоянии языка

— Максим, предлагаю разделить наш разговор на несколько блоков. Первый будет посвящён состоянию языка, потом поговорим о рынке труда, о CMS и фреймворках на PHP и о будущем разработки на PHP.

— Да, давайте.

— На PHP работает практически весь интернет, по разным данным, до 80 % сайтов работает на PHP. Только на WordPress работает около 30 % из всех сайтов и около 60 % из сайтов, которые используют CMS. Как вы считаете, почему в таком случае люди обсуждают, жив PHP или нет?

— Смотрите, всё начинается с цели. У любого языка есть цель, и есть люди и бизнесы, которые ведут язык за собой. Раньше, например, в 2010 году, когда программист начинал бизнес, он приходил в веб и работал на PHP. В то время этот язык был «супер-супер», его все изучали.

Сейчас появился класс бизнесов, которые пришли либо из искусственного интеллекта, либо из Data Science, а там Python. Плюс Python с точки зрения университетов — более стройный язык. К нему есть претензии, но в целом этот язык стройнее и богаче. В нём есть перегружаемые операторы, там можно складывать объекты. То есть это язык для математиков, он изумительно хорош для работы с математическими данными.

Python всё чаще преподают в институтах и университетах, потому что он нравится преподавателям, а также потому, что студент после освоения этого языка сможет хорошо кодить математику, какую-то Big Data или искусственный интеллект. Это близко институтам. Поэтому последние лет 5 формируется поколение программистов, которые знают Python. Они начинают бизнес, приходят в веб и делают что-то на Python.

Здесь есть нюанс: эти люди приходят на рынок, начинают искать питонистов, смотрят — а на рынке 80 % программистов на PHP. Здесь они попадают в неудобное положение. У них код уже написан на Python, поэтому они переучивают PHP-программистов. Получается новая прослойка программистов, которые делают какой-то бизнес, в нём часть, которая отвечает за искусственные интеллект, работает на Python, а веб-представление они тоже автоматически делают на Python — не использовать же два языка. Таким образом Python пролезает в веб.

Ведь любой предприниматель делает бизнес своими руками и своими мозгами. Какой язык программирования он знает, на том языке и будет написан его продукт. Раньше знали PHP, потому что другого языка не было. Действительно, все CMS сделаны на PHP. И поэтому PHP свои позиции не сдаёт.

Представьте, что бизнесмен собирается делать сайты-визитки. Он смотрит, на чём их делают на рынке, и видит, что почти все такие сайты делают на WordPress. Тогда он тоже выбирает WordPress. А WordPress написан на PHP. Поэтому всё идёт от бизнеса — какой бизнес, такой и язык.

— А сам язык PHP скорее жив или скорее мёртв?

— Жив конечно.

— А для чего в 2020 году используется PHP? Какая у него сфера применения или ниша?

— Это всё, что связано с вебом: от простейших сайтов до каких-то больших проектов. Например, тот же Skyeng сделан на PHP. Если вы не пишете большой коробочный продукт класса «1С», хотя веб-часть «1С» тоже на PHP написана, а вы пишете какой-то сайт, который предоставляет услуги, как Skyeng, то его тоже можно писать на PHP. Весь вопрос в том, что знал основатель бизнеса. В случае со Skyeng это был PHP, поэтому сайт написан на PHP. Если какая-то контора выходит на рынок веб-программирования, ей надо использовать PHP без вариантов, потому что под него больше серверов, под него больше услуг, под него больше программистов.

— То есть мы можем сказать, что ниша PHP — веб-разработка?

— Да, этот язык ведь начинался как шаблонизатор. Со временем потребовалось писать на PHP много бизнес-логики, поэтому в него добавили возможности хорошо описывать объекты, чтобы трейты, protected, private появились, чтобы можно было отобразить сложные взаимоотношения, например, на 200 акторов. Потому что когда начинаешь сравнивать языки, например, PHP vs. Python, в последнем что хорошо — можно определить, как объект будет складываться, делиться, вычитаться. В PHP этого нет. А вот, например, как определить protected и private? В Python, по-моему, protected вообще нет. Как определить private-свойства, как они визуально выглядят? Python здесь выглядит несерьёзно. В результате на PHP легче описывать какие-то сложные структуры объектов, они визуально лучше выглядят. Есть возможность работать с интерфейсами, наследованием, трейтами, типами. Бизнес-логику хорошо писать на PHP.

— Максим, вы уже несколько раз упомянули Python. Мы можем сказать, что этот язык конкурирует с PHP на его поле?

— Да, конечно.

— А какие ещё языки конкурируют с PHP?

— Ruby, серверный JavaScript в его реализации через TypeScript. Потому что сам по себе JavaScript — язык нестрогий. Что хорошо в современном PHP — появились типы для аргументов, появились типы для возвратов функций, появилась возможность очень сильно специфицировать код. Мы можем «запереть» код в каком-то слепке: определить, что эта функция возвращает целое число. В JavaScript такого нет, как и в старых версиях PHP. Там наша функция могла строку вернуть, могла число и так далее. TypeScript позволяет специфицировать все входы и выходы.

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

У JavaScript ещё есть важный плюс — серверные и фронтенд-программисты пишут на одном языке. Это большая и важная тема. Если, например, в компании серверный код пишут на PHP, а фронтенд на том же TypeScript, начальнику отдела не удастся быстро перебросить специалиста с фронта на бэк, если понадобится. А если в компании JavaScript и на сервере, и на фронтенде, вы можете это сделать.

— А Java не заходит на поле PHP?

— Нет. Это язык, конечно, присутствует в веб-разработке, но на таком же уровне, как C, C#, C++. У Java не очень большая доля рынка, и этот язык избыточен для веба. Да, приложения на Java будут быстрее и правильнее. Но на Java писать дольше, сложнее. А Java-программистов на рынке меньше.

Если вернуться к бизнесу — вы покупаете хостинг, на него можно поставить PHP и больше ничего. Возможно, вы кое-как найдёте хостинг для Python, для JavaScript, для Ruby. Для Ruby даже вряд ли найдёте. Захотите поставить Java, а на это надо потратить гораздо больше денег.

Java хороша для того, чтобы сайт «М.Видео» на ней написать. То есть этот язык подходит для чего-то большого и сложного. Что важно понимать: когда маленький стартап начинает работать, он толерантно относится к падениям. Ну, упал сайт — клиенты не могли им пользоваться 30 минут. А когда стартап вырос в большую корпорацию, для них эти 30 минут превращаются в миллионные потери. Они на рынок акций вышли, провели IPO. Сайт упал, цена акций снижается, акционеры ругаются. Для них стоимость падения многократно выше по сравнению с маленькими компаниями.

Поэтому у них культура другая. Они стараются 33 раза всё протестировать, выкатывать изменения на прод медленно. Здесь лучше подходит Java. PHP уместен в компаниях, где процесс построен так: «Сейчас выкатим... Ой, что-то упало... Сейчас пофиксим... 7 минут лежал сайт, ничего страшного». Или 7 часов, тоже ничего страшного. А Java лучше подходит для чего-то сложного, тяжёлого и дорогого.

— Максим, немного отвлечённый вопрос: если какой-то пользователь или какой-то бизнес делает свой сайт, на чём ему сегодня лучше его делать? Это будет какая-то CMS, например, WordPress? Возможно, фреймворк — Laravel или Yii2, может, SaaS-решение типа Tilda?

— Это зависит от бизнеса. А бизнес ориентируется на клиента. Я знаю американские бизнесы, у которых остаются телефонные интерфейсы, несмотря на развитие интернета. То есть к ним приходишь на сайт, видишь номер телефона, звонишь и решаешь свои задачи, например, покупаешь шины.

Прежде чем выйти в онлайн, они считают, принесёт ли этот шаг прибыль. Поначалу они стараются использовать что-то дешёвое. Возможно, какие-то SaaS-решения — тот же самый «Эквид». А может, им даже выгоднее на Amazon свои товары выставить на продажу. То есть бизнесы стараются минимально вкладываться, делать всё дёшево.

Если такому бизнесу нужна страница с каталогом, он идёт на WordPress, делает там поддомен, который стоит доллар в месяц. Если нагрузка растёт, они со временем куда-то перейдут. Может, это будет какое-то своё решение. Но в этом смысле предприниматели отталкиваются от того, что используют соседние бизнес-интеграторы.

Например, приходит в студию предприниматель и просит сайт. Студия смотрит — предпринимателю нужен редизайн, а денег от него много не придёт. Поэтому студия идёт на какой-нибудь Templatemonster, покупает готовый темплейт. А этот темплейт сделан под WordPress. В результате студия автоматически делает предпринимателю сайт на PHP. Устанавливают WordPress, сбоку WooCommerce и форум, сверху натягивают готовый шаблон.

WordPress все знают, с ним работает много программистов. Здесь всё уже известно, багов мало. То есть здесь мыслят не категориями языка, язык здесь вторичен. А если человек хочет сделать какой-то аналог «Яндекс.Такси», он будет думать, на чём писать. В первую очередь будет писать на том, что знает сам. Если ему лет 30, будет, скорее всего, на PHP писать. Если он помоложе, его в институте уже на Python учили — будет на этом языке писать.

На стороне PHP играет то, что уже есть сложившийся рынок. Это можно пояснить на примере СТО. Открывать СТО всегда выгодно, потому что есть сложившийся рынок машин. Владелец нового СТО просто откусит от этого рынка ещё один маленький кусочек. Так и в веб-разработке: открывать студию, которая обслуживает существующий рынок сайтов на WordPress и других решений на PHP, выгодно.

— То есть пока есть WordPress, Laravel и другие популярные решения, PHP остаётся востребованным. А может сложиться такая ситуация, что через 10 или 15 лет вместо WordPress на рынке будет доминировать что-то другое, условный Django и Python или что-то ещё?

— Теоретически такое может быть, новые сайты могут делать на чём угодно. Но существующие сайты никуда не денутся. Например, есть какая-то кузница, она делает решётки, у неё сайт с каталогом на WordPress, сайту уже лет 10. Какая цель у кузницы? Они как ковали решётки, так и будут это делать. Возможно, будут выпускать больше продукции.

Появится больше посетителей на сайте, потребуется каталог побольше. Но сайт останется тот же. Кузнице надо закрывать дыры в безопасности и обновлять дизайн раз в 10 лет. И всё — это вечная тема. Через 20, через 50, боюсь, даже через 100 лет они будут работать на WordPress.

Посмотрим на бум мобильников — люди стали через мобильные устройства заходить на сайты. Но появились скины, которые позволяют сайту нормально выглядеть на мобильном экране. Это уровень HTML, CSS и немного JavaScript, к CMS это отношения не имеет.

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

Вот мобильное приложение будет написано на мобильном языке — Swift, Objective-C, на той же Java. А данные это приложение будет получать из WordPress по API, которое есть уже сейчас. Этот сайт на WordPress будет жить, пока живёт стоящий за ним бизнес. И это касается тысяч и миллионов бизнесов: кузнецы, продавцы машин, запчастей, ремонтники, те же кафе. Может со временем бизнесы будут чаще пользоваться какими-то SaaS-решениями. Но здесь уже появляется противоречие между желанием иметь своё и необходимостью пользоваться кусочком в чём-то общем. Это можно сравнить с выбором между своим небольшим магазином и лоточком внутри большого супермаркета.

И ещё здесь появляется вопрос стоимости решения. Возможно, если бы кузнецы делали сайт сейчас, решение на Тильде обошлось бы им дешевле. Но им быстро перестало бы хватать возможностей Тильды. Понадобится какой-то каталог прикрутить — и вот мы снова на WordPress! То есть новые решения будут появляться на Python и на других языках. А старые решения останутся на PHP.

Читайте также

Зачем изучать PHP: рейтинг, перспективы, сферы применения

Если новичок не ленится, если с головой порядок, он через 2 или 3 или 4 года становится мидлом с большой зарплатой: о рынке труда

— Мы определились, что PHP жив. Теперь можно плавно перейти к вопросу, который особенно сильно волнует наших студентов. Это рынок труда. И здесь первый вопрос: с одной стороны говорят, что на рынке очень много специалистов по PHP, а с другой стороны можно услышать, что таких специалистов не хватает. Где правда?

— Смотря о каком специалисте идёт речь. Если у вас маленькая контора, вы пишете сайты на WordPress, вам нужен дешёвый специалист. Он немного знает PHP, немного вёрстку, немного ещё что-то. Таких на рынке десятки тысяч.

А если взять тот же самый Skyeng, там высокие требования к специалистам. Надо знать Symfony, PosgreSQL и другие вещи. Кстати, PostgreSQL не совсем специфична для PHP, здесь роднее MySQL. Так вот, программистов, которые знают много и умеют много, не хватает. Они нужны Skyeng и ещё нескольким десяткам компаний. А остальным 20 тысячам компаний, которые пилят на WordPress маленькие магазинчики, специалисты с такой квалификацией не нужны.

Это копия реальной жизни. Есть сварщик Вася, который кое-как варит заборы по садам. А есть такой же Вася, который варит атомные подводные лодки на большом заводе. И таких специалистов, которые умеют варить подводные лодки, всего пять на всю страну.

— Правда ли, что PHP проще изучать по сравнению с другими языками?

— Я занимаюсь программированием уже 20 лет, и мне кажется, что сложность изучения PHP, Python, Ruby, JavaScript примерно одинаковая. Нельзя сказать, что PHP проще других. Просто из-за его шаблонной природы проще писать первые приложения. Не надо что-то объявлять, не нужен какой-то сервис. Разработчик написал в файле код на PHP, у него уже какой-то сервер установлен, и если к нему обратиться, он в браузере уже что-то выдаёт. То есть первые шаги на PHP действительно делать легче, и в этом плане другие языки не сравнятся с PHP. Но эти шаги длятся два дня, а обучение год. А дальше — у PHP есть проблемы с именованием функций, с порядком аргументов. В других языках тоже есть проблемы — к любому можно придраться.

— Максим, а если бы вы сегодня начали изучать программирования, вы бы начали снова с PHP?

— Я изучал язык под контору. Хотел работать в X-Cart, а в этой конторе требовались PHP-программисты. Купил книгу, месяц почитал, пошёл на собеседование — всё нормально, меня приняли. Человек никогда не изучает языки «абы куда», он всегда изучает языки «почему-то». У него есть целевая контора, которая программирует, например, на Erlang. И он будет изучать этот язык.

Ещё один вариант — человек зашёл на «Хедхантер» и посмотрел, а каких программистов хотят видеть работодатели? Увидел, что нужны специалисты по PHP, Python, C и так далее. Почитал отзывы и выбрал, например, Python. То есть это зависит в том числе от личных предпочтений, потому что, например, не все любят веб.

Возвращаясь к вопросу — мне тяжело судить. Скорее всего, выбрал бы PHP. Просто сейчас я уже хорошо знаю этот язык. И поэтому мне интересно изучать Python или, например, Go. Но я понимаю, что сегодня мной движет любопытство. Это даже не вопрос денег. Зарплаты плюс-минус одни и те же у специалистов по этим языкам.

— Если взять гипотетического новичка, который прилежно изучал PHP, у него голова на месте, руки на месте. Этот человек найдёт работу?

— Конечно.

— А где сейчас работают PHP-программисты? Это аутсорс, продуктовые компании, энтерпрайз, что-то ещё?

— В целом это веб-разработка. Это и маленькие студии, которые делают маленькие сайты, и средние студии, которые делают сайты каким-то заводам, и большие студии, которые делают проекты масштабов «М.Видео». Это и аутсорс на Запад, там тоже много работы для PHP-программистов. Аутсорсеры пишут для Европы, для США и Канады, даже для Аргентины и Бразилии. Есть конторы, которые делают коробочные продукты. Есть аутсорс для коробочных команд. Есть команды, которые делают сайт как продукт или как сервис. Например, Skyeng. Даже Facebook на PHP работает. Понятно, что сейчас его там мало осталось, но тем не менее. То есть это весь спектр веба — буквально всё.

— Максим, вы уже упоминали о требованиях Skyeng. А если абстрагироваться и попробовать дать рекомендации новичкам: что нужно знать начинающим PHP-программистам, чтобы уверенно выйти на рынок труда?

— Сейчас много онлайн-курсов. Новичок приходит на курс, его учат основам языка. Потом учат работать с веб-сервером, с фреймворками типа Laravel или Symfony. Также на курсах новичок пишет какие-то учебные приложения. И после этого приходит на «Хедхантер», говорит, что он джуниор, готовый работать за 35 000. Его берут на работу, дают его условные 32 000. Там он набирается опыта. И здесь появляется вопрос мотивации и головы. Если новичок не ленится, если с головой порядок, он через 2 или 3 или 4 года становится мидлом. Он переходит в другую контору на другую зарплату. Здесь ему уже платят 80 000 или 100 000. Проходит ещё 2-3 года — он становится синьором с зарплатой от 120 000. То есть в начале пути надо набраться опыта: научиться работать с базой, с API и так далее. Есть такой нюанс: заранее углубляться в какие-то темы — это не всегда хорошо. Может, за исключением каких-то абстрактных вещей, например, архитектурных паттернов. Нельзя заранее знать, с чем придётся работать.

Большинству продавцов машин, бутербродов или кошек с собаками всё равно, на чём у них сайт: о WordPress и других инструментах

— От рынка труда предлагаю плавно или не очень перейти к фреймворкам и CMS, которые есть в экосистеме PHP. WordPress — явный лидер на рынке CMS и вообще в вебе. А за счёт чего ему это удаётся?

— Это совокупность факторов: усилия маркетинга, партнёров, программистов. Это работа со сторонними авторами модулей. Это создание инфраструктуры для этих авторов модулей. Например, важную роль играет удобный маркетплейс, где авторы модулей могут продавать свои продукты. Это усилия тысяч людей. В целом на успех влияет и профессионализм программистов, которые писали ядро, и визионерские качества CEO, который выбрал правильное направление развития.

— Но это ведь опенсорсный проект, там нет централизованной разработки, насколько я понимаю?

— Рядом с любым опенсорсным проектом всегда есть какие-то конторы, которые на нём зарабатывают деньги. Здесь можно передать привет, например, Red Hat. Сам проект может быть опенсорсным, а коммерческие конторы, которые находятся рядом с ним, адаптируют продукт так, чтобы его могли использовать люди и сторонние бизнесы. Это фактически сегмент B2B. Например, бизнесу надо сделать сайт. Он смотрит — вот хороший партнёр! Большинству продавцов машин, бутербродов или кошек с собаками всё равно, на чём у них сайт, они этого могут даже не знать. Зато они знают, что у них есть хороший партнёр, которому можно доверить сайт.

— Максим, на профессиональных ресурсах можно найти скептические комментарии насчёт WordPress. Можно заметить, что профессионалы его не любят. Так ли это, и если да, то почему?

— Это старый разговор про продукт, у которого очень много пользователей. Когда продуктом пользуется много людей, ему сложно идти вперёд в технологическом плане. То есть он без багов, но он построен по-старому. Старый код тянет за собой старые технологии. С одной стороны, людям хочется использовать что-то новое. А с другой стороны, они хотят преемственности и совместимости — чтобы на новый WordPress без проблем становились их модули. Если выйдет обновлённый WordPress, который будет сделан строго под PHP 7.4, и на него не встанут модули, программисты об этом узнают постфактум, когда их уволят. Потому что гипотетическая контора, которая делает модули под WooCommerce, вдруг понимает, что ей придётся переписывать все модули, у неё просто денег на это не хватит. Она закроется. И вот тут радостные программисты, которые получили WordPress с новыми фишками и фреймворками, вдруг оказались уволенными. Поэтому в реальности программисты будут вечно недовольными из-за использования старых технологий, но у них будут зарплаты.

— Вы вспомнили фреймворки. Скажите пожалуйста, в каких ситуациях они подходят лучше, чем CMS?

— CMS подходит, когда нужен простой сайт, на котором будет информационная часть, небольшой каталог или магазин и всё. Фреймворк нужен, если вы делаете «сходу неведомо чего». Это может быть какой-то сервис, например, конкурент «Яндекс.Такси», систему доставки, у которой не будет пересечений с CMS. То есть CMS предоставляет много готового кода, а при использовании фреймворков нужно писать код самим. Это можно сравнить с такой ситуацией: нужно перевести пять коробок с футболками из Ульяновска в Москву, вы заказываете услуги СДЭК и решаете задачу. А если нужно перевезти по этому же маршруту дом, СДЭК не поможет.

— Немного подробнее о фреймворках в PHP: у нас есть Laravel, Zend, Yii2, Symfony и другие решения. За какими из них настоящее и будущее?

— У Yii2 есть свои апологеты. Это нормальный фреймворк, он не слишком тяжёлый, как Symfony. Под Symfony есть много бандлов, но он тяжеловатый и слишком энтерпрайзный. Laravel полегче. Но, опять-таки, всё зависит от цели. Если нужно строить что-то большое, и вы знаете Symfony, вы будете использовать этот фреймворк. Если нужно что-то не очень большое, какой-то интернет-магазин, можно выбрать Laravel. Все фреймворки похожи, в них используется модель MVC. Надо знать хотя бы один. Фактически бизнес выбирает то, что знает. А разработчик не выбирает. Он приходит в компанию, где пишут на Laravel. Что делать? Придётся выучить. На это уйдёт 3-4 дня.

— В Ruby есть «рельсы», в Python есть Django — фреймворки-лидеры, вокруг них всё крутится. А в PHP несколько лидирующих фремворков. Это хорошо или плохо для разработчиков, для сообщества?

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

Большое количество фреймворков — следствие того, что самого языка PHP много. Его использует огромное количество людей, у них свои мысли и идеи. Здесь крутятся миллиарды долларов. Какая-нибудь контора выпускает свой фреймворк. А эта контора — второй по размерам интегратор в США. Этот фреймворк будет использоваться на десятках тысяч сайтов.

На Python и Ruby меньше сайтов. Там есть один фреймворк — и хорошо. А чтобы появились новые фреймворки, нужны десятки тысяч контор, которые зарабатывают миллионы и миллиарды. Тогда появятся люди, которые скажут, условно, что Ruby on Rails нам не нравится, мы сделаем свой новый фреймворк.

Все эти фреймворки — «рельсы», Django, Flask и так далее, их разработчики отталкивались от фреймворков, которые написаны на PHP и Java.

Большое количество фреймворков в PHP — это ещё и следствие его эволюции. Люди выясняли, каким будет веб. Была статика, были шаблоны, потом появился AJAX, что-то стало на фронтенд перетекать... Это следствие эволюции — старый фрейморк попадал в ловушку, как WordPress. Люди ждут фреймворк с новым кодом, в котором работают старые методы. А такого не бывает.

Так, например, ушёл Zend — его съела Symfony. Zend ушёл, но не умер. Он остался на старых сайтах, которые нужно поддерживать. И программисты вынуждены его знать. Появился сложный Symfony, потом появился Yii, который проще — это эволюция.

Если ты строишь свой Ruby на чём-то уже готовом, например, на PHP — все ошибки до тебя уже сделаны. Поэтому и фреймворков будет меньше.

Начало

Сервер у нас пусть будет на ​ CentOS​. Оптимизировать будем методом правки конфига ​my.cnf​ .

Настройка некоторых параметров может повысить
производительность БД сервера в несколько раз!

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

Для этого возьмем ​ htop​ (как красивый и наглядный инструмент):

yum install htop

Выведем ​ htop​ :

htop

Получаем нечто такое:
Запишем себе в ​my.cnf​:

# 3 ядра, 4гб оперативной памяти 

Теперь давайте узнаем количество таблиц и их типы.
Для этого возьмем ​mysql tuner​:

wget https://raw.github.com/major/MySQLTuner-perl/master/mysqltuner.pl

Запустим:

perl mysqltuner.pl

Вывод примерно:

image

Запишем себе в ​my.cnf:

# 64M myisam, 770M innoDB

Типовой конфиг обычно рекомендуют какой-то такой:

[client] 
port                        = 3306 
socket                      = /var/run/mysqld/mysqld.sock 

[mysqld_safe] 
socket                      = /var/run/mysqld/mysqld.sock 
nice                        = 0 
 
[mysqld] 
user                        = mysql pid-file                    = /var/run/mysqld/mysqld.pid 
socket                      = /var/run/mysqld/mysqld.sock 
port                        = 3306 
basedir                     = /usr 
datadir                     = /var/lib/mysql 
tmpdir                      = /tmp 
language                    = /usr/share/mysql/english 
old_passwords               = 0 
bind-address                = 127.0.0.1 
 
skip-external-locking 
 
max_allowed_packet          = 16M 
key_buffer_size             = 16M 
innodb_buffer_pool_size     = 2048M 
innodb_file_per_table       = 1 
innodb_flush_method         = O_DIRECT 
innodb_flush_log_at_trx_commit  = 0 
 
max_connections             = 144    query_cache_size 
= 0 slow_query_log              = /var/log/mysql/mysql-slow.log 
long_query_time             = 1 
 
expire_logs_days            = 10 
max_binlog_size             = 100M 
 
[mysqldump] 
quick 
quote-names 
max_allowed_packet          = 16M

Теперь давайте разбираться, что мы будем оптимизировать здесь, зачем, как и почему (особенно почему этих параметров маловато.

Оптимизация и конфиг

Для начала можно пролистать в конец вывода ​mysql tuner​ и посмотреть, что же он там рекомендует. В нашем случае это выглядит как-то так:

wget 
https://raw.github.com/major/MySQLTuner-perl/master/mysqltuner.pl 
perl mysqltuner.pl

image

Не будем заниматься бездумной подстановкой, а пройдемся по параметрам ​mysql​ , которые могут нас интересовать в первую очередь. Что к чему:
skip-external-locking​, — убирает внешнюю блокировку, что быстрее;
skip-name-resolve​ , — позволяет ​MySQL ​ избегать ответа на запрос DNS ​ при проверке подключения клиентов к серверу ​MySQL​ .

Таким образом, сервер ​MySQL ​ будет использовать только
IP​ -адреса, а не имена хостов, что немного, но быстрее.

binlog_cache​ _ ​ size​, — размер кэша для хранения изменений в двоичном журнале. Задает размер только для кэша транзакций. Сделаем ​ 100M​ — больше не нужно.

innodb_stats_on_metadata​ =​ 0 (OFF),​ — для ускорения работы с
INFORMATION_SCHEMA​, ​ SHOW TABLE STATUS​ или ​ SHOW INDEX​ отключим обновление статистики при выполнении таких операций

quer​ y ​ _cache_size ​ = ​ 128M ​ и ​ query_сache_type​
​ = ​ 1
,​ ​ — ​ кэши запросов. ​ 1​ — в принципе включен, ​ 128M​ ограничение. Не
рекомендуется ставить выше ​ 256M​ , т.к это может привести к блокировке.

Так как у нас больше​InnoDB​ таблиц, то зануляем cache​ _ ​ size​ .
С версии MySQL 5.6 ​ query_cache_size​ отключен, а с версии 8.0 удален

Стандартно все таблицы и индексы хранятся в одном файле, поэтому используем ​ innodb_file_per_table = 1.

Значение ​ innodb_open_files​ и ​ table_open_cache​ — рекомендуется устанавливать обе опции в ​ 4096 ​ или ​ 8192​ . А вообще рассчитывается как количество таблиц во всех базах, умноженное на ​ 2​ , ориентировочно.

При работе с ​ InnoDB ​ является важнейшим параметр innodb_buffer_pool_size​ , ​ он устанавливается по принципу «чем больше, тем лучше». Рекомендуется выделять до ​ 70-80% оперативной памяти сервера.

innodb_log_file_size​ — влияет на скорость записи, устанавливает размер лога операций (операции сначала записываются в лог, а потом применяются к данным на диске). Чем больше этот лог, тем быстрее будут работать записи (т.к. их поместится больше в файл лога). Файлов всегда два, а их размер одинаковый. Значением параметра задается размер одного файла.

ВНИМАНИЕ!️При изменении параметра innodb_log_file_size остановите MySQL, сделайте резервную копию файлов ib_logfile-n (файлы чаще всего лежат в /var/lib/mysql/), измените значение параметра innodb_log_file_size и запустите MySQL. В результате
MySQL создаст новый лог-файл указанного в конфигурации размера.

Установка большого размера ​ innodb_log_file_size​ может привести к увеличению быстродействия, но при этом увеличится время восстановления данных, выберите от ​ 256M​ до​ 1G​ .

innodb_log​ _ ​ buffer_size​ — размер буфера транзакций. Обычно рекомендуется не применять, если не используете ​ BLOB ​ и ​ TEXT больших размеров.

innodb_flush​ _ ​ method,​ — определяет логику сброса данных на диск. В современных системах при использовании RAID и резервных узлов, вы будете выбирать между ​ ODSYNC​ и ​ ODIRECT, — первый параметр быстрее, второй безопаснее.

key_buffer​ _ ​ size​ — буфер для работы с ключами и индексами, и sort_buffer​ — буфер для сортировки. Если Вы не используете MyISAM ​ таблицы, рекомендуется установить размер key_buffer_size ​ в ​ 32Мб ​ для хранения индексов временных
таблиц.

Параметр ​ thread_cache​ _ ​ size​ указывает количество тредов (threads), уходящих в кеш при отключении клиента. При новом подключении тред не создается, а берется из кеша, что позволяет экономить ресурсы при больших нагрузках.

innodb_flush_log_attrx_commit​, — может повысить пропускную способность записи данных в базу в сотни раз. Он определяет, будет ли ​Mysql ​ сбрасывать каждую операцию на диск (в файл лога).

innodb_flush_log_at_trx_commit = 1​ используется для случаев,
когда сохранность данных — это приоритет номер один.

innodb_flush_log_at_trx_commit = 2​ для случаев, когда небольшая потеря данных не критична. Есть еще 0 (ноль) — самый производительный, но небезопасный вариант.

max_connections ​ — если вы получаете ошибки "​ Too many connections​ ", эту опцию стоит увеличить. А так большой пользы в оптимизации от неё нет.

Количество потоков ввода/вывода файлов в InnoDB задается опциями ​ innodb_read_io_threads​ , ​ innodbwrite_io_threads​, обычно этому параметру присваивается значение ​ 4 ​ или ​ 8​ , на быстрых ​ SSD​ -дисках установите в ​ 16​. Значение innodb_thread_concurrency​ установите в количество ядер ​ * 2​ .

Конфиг получается вот такой:

[client] 
port                        = 3306 
socket                      = /var/run/mysqld/mysqld.sock 
 
[mysqld_safe] 
socket                      = /var/run/mysqld/mysqld.sock nice                        = 0 
 
[mysqld] 
user                        = mysql 
pid-file                    = /var/run/mysqld/mysqld.pid 
socket                      = /var/run/mysqld/mysqld.sock 
port                        = 3306 
basedir                     = /usr 
datadir                     = /var/lib/mysql 
tmpdir                      = /tmp 
language                    = /usr/share/mysql/english 
old_passwords               = 0 
bind-address                = 127.0.0.1 
 
skip-external-locking  
skip-name-resolve 
 
binlog_cache_size = 100M 
thread_cache_size = 32 
 
innodb_stats_on_metadata = OFF 
 
query_cache_limit = 1M 
query_cache_size = 0 query_cache_type = 1 
 
innodb_buffer_pool_size = 3G 
innodb_log_file_size = 256М 
innodb_log_buffer_size = 6M 
innodb_additional_mem_pool_size = 16M 
innodb_flush_method = O_DSYNC 
innodb_flush_log_at_trx_commit = 0 
innodb_thread_concurrency = 6 
innodb_file_per_table = 1 

 
key_buffer_size = 32M 
tmp_table_size = 64M 
max_connections = 350 
sort_buffer_size = 16M read_buffer_size = 1M 
read_rnd_buffer_size = 1M 
join_buffer_size = 8M 
thread_stack = 1M 
binlog_cache_size = 8M 
 
tmp_table_size = 128M 
table_open_cache = 2048 
 
[mysqldump] quick 
quote-names 
max_allowed_packet = 16M

Ну и напоследок можно посмотреть рекомендации тюнера и последовать им.

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

Либо вы не найдете такого пункта в админке CMS среди множества других настроек (логика авторов движков при размещении некоторых пунктов настройки остается непонятной и, возможно, здесь играет определенную роль сила привычки самого автора), либо разработчики вообще не включат такой пункт в админку системы управления контента. Невозможно реализовать настройки для всего через админку — туда, обычно, выводят только самые необходимые и часто используемые настройки.

Зачастую бывает проще решить проблему не штатными, предусмотренными в админке движка средствами, а напрямую, правя что-то в базе данных или же корректируя содержимое определенных файлов движка через доступ к ним по ФТП.

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

Начну я, конечно, с оформления вебстраниц (собственно, на данный момент я уже это дело закончил и вы можете ознакомиться с результами тут и тут). Как я уже упоминал в одном из предыдущих постов, до недавнего времени все ресурсы состояли из страничек в формате HTML. Причем, там задавалось и наполнение вебсайта (тексты, изображения, таблицы) и его оформление (цвета, фон, отступы).

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

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

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

C появлением таблиц стилей многие теги языка гипертекстовой разметки и их атрибуты стали считаться устаревшими и не рекомендованными для использования. Вместо них советуют использовать свойства CSS, выполняющие те же действия. Это отнюдь не означает, что HTML теперь уже изучать не надо, просто уменьшилось количество тегов и их атрибутов, которые надо знать и уметь использовать для создании и поддержания в должном состоянии сайта. Я постараюсь рассказать про те теги, которые я сам постоянно использую.

В каком редакторе лучше править или вносить изменения в код

Ничего сложного в этом нет, ведь по сути это даже не язык программирования, а гипертекстовая разметка, нечто похожее на синтаксис в русском языке. Что хотелось бы сразу посоветовать, опираясь на собственный опыт? Пробуйте писать теги самостоятельно в блокноте, типа Notepad++ (читайте мой обзор этого редактора), а не в программах, типа Дримвьювер. Почему?

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

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

Хотя, это мое личное мнение (ИМХО) и вам решать, что удобнее. Например, Евгений Попов, по курсам которого я изучал все это дело, судя по всему, приверженец Дримвьевера. Важно в принципе одно – чтобы вы правили код в том редакторе, который способен сохранять все внесенные изменения и который может, при желании, вернуть все как было (взад).

В этом случае, как бы вы не напортачили, все будет поправимо. И, конечно же, очень удобна подсветка синтаксиса языка, на котором вы пишете или редактируете код. Notepad++ — это безусловно мой выбор! О его возможностях я рассказал в приведенной чуть выше статье.

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

В то время, как теги вебстраниц в современной CMS не записаны в каком-то одном или нескольких файлах, как было раньше, а генерируется (интерпретируется) из PHP. И именно уже сгенерированный таким образом Html код подсовывается браузеру для того, чтобы он в свою очередь интерпретировал его в удобоваримую для нас форму интернет-странички. Хитро, не правда ли?

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

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