Научный консалтинг
Главная
Контакты
Номер телефона
Как мы работаем
Гарантии
Условия
Цены

Как научиться вебпрограммированию или
Древо познания для сайтостроителя

У начинающих программистов нередко возникает вопрос: с чего начать при изучении вебтехнологий, т.е. чтобы научиться создавать сайты? Какие технологии и программные продукты изучить? Конечно, каждый отвечает на этот вопрос – кто во что горазд. Зачастую, отвечает, исходя из своего собственного или знакомых – опыта. А как будет правильнее – с точки зрения оптимальности обучения? Этому посвящена наша статья.

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

Во-первых, следует четко определиться для себя, чем конкретно Вы собираетесь заниматься (возможна, конечно, комбинация вариантов):

  • созданием html-кода сайта,
  • дизайном,
  • реализацией функциональности сайта (собственно – программированием),
  • администрированием сайта (правда, это уже не относится к сайтостроению).

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

Если Вы твердо решили не вникать в функциональность, ограничившись лишь созданием страниц на чистом html и, быть может, заниматься дизайном сайтов, тогда все несколько проще: Вам следует изучить язык html на достаточно серьезном уровне, плюс – освоить язык CSS (правила создания стилей для оформления и некоторой функциональности), потому как современные сайты на совсем уж чистом html не делаются. И, пожалуй, пока все. Потом можно будет дополнять объем своих знаний разного рода технологиями типа SVG, flash, осваивать микроразметку и др.

Вообще, надо сказать, многие программисты разделяют процесс создания html-страниц и процесс программирования. Язык html они языком программирования не считают.

Что, отчасти, неверно. Дело в том, что в последние годы в html/CSS появилось множество новых свойств и возможностей, которые содержат в себе элементы программирования (взять те же @media или функцию calc). Кроме того, в ряде случаев создания вебстраницы, например, при проектировании меню, адаптивного дизайна и т.д. – необходимо использования html + СSS, что называется, с умом. Это когда расположение элементов страницы и/или их внешний вид задается в зависимости от разрешения экрана устройства, на котором эта страница будет открываться и просматриваться. А также от некоторых других его характеристик. «Просто разметкой» страницы в таких случаях уже не обойтись, необходимо, именно – программировать положение и стили элементов страницы при помощи стилей CSS. Иногда приходится, скажем так, сильно «исхитряться», чтобы создать разметку, которая способна качественно изменяться в зависимости, допустим, от ширины экрана устройства. Ведь не секрет, что в настоящее время диапазон видов устройств, с которых можно открыть вебстраницу, весьма широк.

Отметим, что очень часто, в целях то ли облегчения, то ли незнания языков html и CSS, многие создатели вебстраниц вместо грамотного использования свойств CSS предпочитают использовать для оформления страниц javascript. Точнее, чаще всего применяют для этой цели готовые, уже созданные кем-то ранее, библиотеки, адаптивные шаблоны и др. (об этом речь – ниже). В большинстве же случаев и вовсе используется готовая программная среда для сайта (система управления контентом или CMS), будь то Wordpress, Joomla!, Drupal, Vbulletin и т.п.

Такой подход допустим, если некритична скорость открытия вебстраницы сайта или – если сайт не особо сложный или сделан "для галочки". Или если сайт работает на каком-нибудь сверхскоростном суперсервере. Однако, если критична скорость открытия (загрузки) страниц сайта, особенно в случаях, когда над проектом трудятся далеко не один и не два человека, и когда их состав периодически меняется – в итоге проект разрастается, добавляется огромное множество разных библиотек (каждый разработчик, зачастую, вносит свой, так сказать, «вклад»), плагинов, в итоге появляются «глюки», страница такого сайта открывается секунд 10…40 – даже в условиях высокой скорости интернета и производительного сервера. Естественно, заказчик такого сайта услышит от программистов что-то типа: «здесь реализованы очень сложные технологии, Вам надо учиться, чтобы понять, о чем речь». Но, поверьте на слово, в 99% случаев истинная причина ВОВСЕ не в этом. Ну, это так бывает, наверное, практически везде (от уборщицы – до президента России): кое-кому проще воспользоваться неосведомленностью заказчика в технических или иных вопросах, спихнув на это свои недоработки.

Итак, для «чистого» создателя вебстраниц будет достаточно html + CSS.  

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

Кроме того, существуют и иные направления, которые неплохо бы знать вебмастеру, особенно, если он делает на сайте все САМ. Особенно, если его сайт находится на выделенном сервере, где он сам себе хозяин. Это, в частности, хотя бы минимальные навыки обслуживания сервера, в любом случае – это азы настройки сервера и серверного языка (например, РНР). Для облегчения восприятия, на схеме ниже отображена предлагаемая, на наш взгляд - оптимальная) динамика развития вебпрограммиста, как специалиста. Объяснения идут ниже.

Схема развития уровня познаний вебпрограммиста

Отметим сразу, что схема является немного упрощенной.



Рассмотрим основные моменты приведенной схемы

Итак, таков, на НАШ ВЗГЛЯД, оптимальный порядок, динамика освоения сайтостроения. В первую очередь, как уже говорилось, естественно, необходимо надлежащее знание языка html и правил CSS. Без этого не стоит браться за мало-мальски серьезный сайт.

А вот далее – возможны варианты. Если не хочется возиться с программированием, то вполне можно воспользоваться готовым решением – шаблоном, для чего можно использовать CMS. Их на данный момент – великое множество, как платных, так и бесплатных. Если придерживаться именно варианта, который предусмотрел разработчик той или иной CMS, ничего не меняя ни в структуре, ни в функциональности сайта, то его создание получится довольно быстро – в течение 1…2 дней. Остается только установить CMS на хостинге (сервере), снабдить сайт контентом и, быть может, выполнить необходимые настройки сервера (в том числе, файла .htaccess, php.ini и др.). И все. Сайт может работать.

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

Однако, более-менее серьезный сайт в будущем, как правило, требует дополнительной или попросту ИНОЙ функциональности. Ведь разработчик CMS чисто физически не может предусмотреть всего на свете. В данном случае у владельца сайта есть два пути: либо вносить изменения в код CMS, дополнять функциональность разного рода плагинами, библиотеками, либо – переходить на другую CMS.

Дополнение рано или поздно приводит к несовместимости CMS и библиотек, плагинов (это в 80% случаев так, если над сайтом поработали в свое время разные команды разработчиков) и, кроме того, в результате даже относительно небольшой сайт начинает тормозить. Как следствие – посетители обижаются, затем – раздражаются и уходят с сайта. А ведь он, видимо, создавался с противоположной целью. Ну, как правило.

Переход на другую CMS – дело непростое. Ведь придется анализировать, а то и пробовать, тестировать на собственном опыте не одну и не две их (ведь не все нюансы становятся известными в первые же дни). А это – большие затраты времени. Кроме того, «переезд» всего сайта на другую CMS в ряде случаев сам по себе непрост: ведь новая СМS может использовать, к примеру, иной тип баз данных. Если сайт – динамический (т.е. вебстраница собирается на лету из кусочков, содержащихся в разных файлах/базах данных), то несопоставимость баз данных влечет невозможность быстрой замены CMS.

Конечно, существуют, своего рода, конвертеры, облегчающие такой переход, однако, в любом случае, это – не настолько уж тривиальная задача. В особо тяжелых случаях придется все делать вручную или создавать соответствующее программное обеспечение САМОСТОЯТЕЛЬНО. Начинающему вебмастеру все это, как правило, не по силам. Поэтому – использовать CMS или нет – каждый решает сам.

Решено – делать сайт самостоятельно. В первую очередь - фронтенд

Если же принято решение – делать сайт самостоятельно, то тогда следующий этап в изучении вебмастеринга – это фронтенд. Т.е. придание функциональности страницам html. Основным средством (языком) для этой цели является javascript или его аналоги. Код, написанный на этом языке, выполняется браузером и может осуществлять самые разные задачи по управлению открытой в браузере вебстраницей:

  • изменять стили и ее контент;
  • взаимодействовать с сервером;
  • взаимодействовать с пользователем.

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

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

Однако, на чистом javascript в настоящее время программисты работают мало, как правило, используют соответствующие библиотеки (написанные на нем и облегчающие программирование функциональности вебстраниц). Подобных библиотек, на самом деле, в настоящее время – великое множество. Иногда даже кажется, что JS-библиотек и фреймворков больше, чем javascript-разработчиков. На май 2017 года поиск по GitHub выдает более, чем 1,1 миллион проектов на JavaScript. На npm.js находится 500 тысяч активно используемых пакетов с почти 10 миллиардами скачиваний каждый месяц. Вдумайтесь в эти цифры…

Следует четко понимать, что НИКАКОЙ новой функциональности НИ ОДНА из библиотек javascript не привносит (ибо ВСЕ они написаны на javascript). Все возможные достоинства JS-библиотек ограничиваются следующим:
  • удобство при использовании, написание меньшего объема кода,
  • экономия времени при работе над сайтом (в том числе, за счет заложенной в эти библиотеки кроссбраузерности, т.е. правильного, одинакового функционирования в разных браузерах).
И все. Минусами являются – замедление работы сайта, а также - возможные ошибки в библиотеках и их возможная несовместимость. Что, в общем-то, не такая уж и редкость. Да, конечно, так называемые «баги» так или иначе устраняются разработчиками библиотек, но – тем не менее. Если же библиотека находится на другом сайте – иной раз добавляется еще одна проблема – его перегруженность, что приводит к еще большему замедлению. Вот почему иной раз, даже простенькие с виду сайты, не несущие в себе сложной функциональности и не содержащие большого объема контента на открываемой странице, иногда открываются очень медленно. Пользоваться такими сайтами или нет – дело, естественно, сугубо личное.

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

Впрочем, как правило, с широко известными библиотеками особых проблем программисты не испытывают.

Кроме того, существуют некоторые надстройки над javascript. В целом, их назначение заключается в «облегчении» (как считают разработчики и ряд программистов) использования javascript, а также – в контроле правильности написания соответствующего программного кода.

На наш взгляд, эти надстройки, разного рода "синтаксические сахара" (типа CofeeScript) годятся лишь, что называется, для смены деятельности (для разнообразия или отдыха от работы), а также – для обсуждения их в интернете. Обсуждения исходят, зачастую, от людей, толком не знающих javascript и потому испытывающих к нему определенное неприятие. Это же касается, в определенной степени, и тех, кто привык пользоваться библиотеками. Дело, иной раз, доходит до того, что человек спрашивает где-нибудь на форуме – как, мол, выполнить такую-то операцию, например, на jQuerry. Тут ему приводят пример, как на чистом javascript эта операция делается в ОДНУ небольшую строчку…

Естественно, javascript – не идеален. Именно потому относительно недавно компания Google, к примеру, выпустила свой вариант клиентоориентированного языка под названием Dart. Однако, вплоть до сегодняшнего дня он пока мало распространен, практически все браузеры его еще не поддерживают. Поэтому говорить о его сколь угодно серьезном применении на данный момент – преждевременно.

Далее - бэкенд

Кстати, а почему – не наоборот? Почему бы, вначале, не освоить серверные технологии, а потом уже – киентские?

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

  • заголовки протоколов прикладного уровня (например, HTTP, HTTPS),
  • html-контент открываемой страницы, в том числе -
  • javascript-код.

Последний иной раз входит в состав кода html страницы.

Чтобы понимать и знать, какой конкретно контент должен быть передан сервером браузеру клиента, очевидно, необходимо знать его (контента) «устройство» и функциональность. А для этого нужно знать html и javascript, соответственно. Иначе говоря, знание серверных технологий будет бесполезно, если программист не понимает, для какой цели, что именно будет реализовываться этими технологиями.

Надо сказать, что зачастую в российских ВУЗах встречается все наоборот: вначале студентов учат, допустим, базам данных (а там не обойтись без, хотя бы простейшего, знания PHP или иного серверного языка). А в следующим семестре они изучают язык html и какой-либо серверный язык. Это неправильно.

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

Это могут быть языки С, С++, С# (си-шарп), а также РНР, Perl и ряд других. Языки С/С++ (не С# !!) хороши своей быстротой. Серьезные, нагруженные  сайты во многих случаях делаются именно при их помощи.

Кстати, следует иметь в виду, что применение того или иного языка возможно для соответствующей операционной системы, в которой работает сервер (хостинг). Чаще всего используется ОС Linux (примерно на 75% хостингов). Соответственно, для нее возможно применение С/С++. Однако, есть и серверы, работающие под управлением других ОС, например, Windows. Для последней можно применять также и язык С#.

Бытует мнение, что, мол, написание серверной части сайта на языке С или С++ таит в себе большие сложности. На самом деле, нет. Ибо вполне возможно (и так делается) поступить следующим образом. Те модули, которые не являются ресурсозатратными, но их сложно выполнить на С (С++, С#), реализуются, скажем, на РНР (или на Питоне). А остальная, наиболее нагруженная, часть делается на том же РНР. После чего, из программы РНР делаются вызовы программ, написанных, к примеру, на С. И все.

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

Кстати, в этом, как видится, состоит одна из причин того, что язык Питон (Python) является до сих пор популярным у некоторых разработчиков по сравнению с РНР: ибо последний имеет меньше возможностей. А, используя Питон, можно не затрудняться программированием затратных процедур на языках более низкого уровня (С/С++). Хотя, РНР, вроде бы, удобнее, чем Питон.

Поэтому, честно говоря, несколько непонятны причины многочисленных рассуждений на форумах на предмет того, что, мол, на С или С++ сайт делать «сложно» и затратно. Конечно, если делать это «с нуля», то – да. Если делать, толком не зная языков С (и т.п.) – то, тем более. Да, при программировании на С библиотека jQuerry не поможет – это следует принять к сведению. Но, по нашему опыту, при наличии приемлемых навыков владения языками С и РНР – указанная комбинированная структура серверной части сайта не представляет особой сложности по сравнению, скажем, с разработкой на чистом РНР.

Конечно, использование кода на С/С++ в большинстве случаев приведет к отсутствию кроссплатформенности. Т.е. программу на языке С, написанную в одной операционной системе, придется адаптировать, при необходимости, под другую систему, скажем, Windows или MacOS. Тогда как реализация на чистом РНР, за редкими исключениями, лишена такой необходимости.

После того, как выбран язык, на котором будет программироваться серверная часть сайта, необходимо его освоить. И только ПОСЛЕ (а не ДО) этого можно, при желании, использовать соответствующие библиотеки или фреймворки. Для подавляющего большинства серверных языков (будь то С++, РНР, Питон) существуют свои библиотеки. Использовать их или нет – каждый разработчик решает за себя. Опять же, плюс будет – в ускорении производительности работы над программным кодом. А минус, как и в случае с javascript-библиотеками – замедление работы сайта (правда, здесь оно – небольшое, как правило, так как сервер, зачастую, работает намного быстрее, чем средний клиентский компьютер) и возможность конфликта разных библиотек друг с другом и некорректной их работы.

Но, тем не менее.
Серверный javascript

В последние годы наметилась тенденция в использовании серверного javascript. Это, в первую очередь, набирающий популярность Node.JS. Честно говоря, в ряде случаев необходимость его использования вызывает сомнения, за исключением ситуаций, когда, к примеру, необходимо на сервере хостинга реализовать дополнительный – виртуальный сервер. А также – в некоторых других специфических ситуациях. В остальных же случаях это нам видится пустым экспериментированием и ненужной тратой времени (как минимум – на изучение данной технологии). Поэтому для подавляющего большинства сайтов использование серверного javascript, на наш взгляд, нецелесообразно. Равно нецелесообразны и затраты времени на его сколько угодно серьезное изучение.

Ведь задачи сервера и клиента, как правило, являются КАРДИНАЛЬНО РАЗНЫМИ. Сервер должен сформировать вебстраницу и передать ее клиенту (браузеру). Тогда как клиент – принять ее (результат работы сервера), отобразить и выполнить ту функциональность, которая в ней запрограммирована. Поэтому обольщаться «одинаковым» стилем программирования как на сервере, так и на клиенте – не стоит, в общем случае.

Опять-таки, если Вам все же потребуется серверноориентированный javascript, для облегчения работы с виртуальным сервером (типа Node.JS) имеются немало соответствующих библиотек. Применяются они, в целом, гораздо реже, чем та же jQuerry (на клиенте) или библиотеки для серверных языков PHP, Питон и т.п.

Базы данных

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

Вопрос об актуальности баз данных оставляем открытым. С одной стороны, они представляют собой быстродействующее средство хранения структурированной информации; именно потому базы данных в 90...99% случаев используют для реализации динамического сайта. С другой стороны – необходимо тратить время на их освоение (что, впрочем, не настолько уж сложно). Наконец, нередко на практике выявляются факты взлома баз данных, обусловленные ошибками их разработчиков. Да, после этого последние исправляют эти ошибки, делают патчи… Но, потом выпускается НОВАЯ версия базы соответствующей данных (например, той же MySQL), которая, в свою очередь, потом также обнаруживает ошибки. И т.д. Поэтому использование их, на самом деле, находится под некоторым вопросом.

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

Иногда можно встретить возражения, что, мол, из файлов информация будет считываться дольше, что приведет к снижению скорости работы сайта. Однако, это не так. При условии, конечно, что работа с файлами будет осуществляться при помощи программных модулей, написанных на С/С++. А не на Питоне или РНР.

Впрочем, по нашему опыту, грамотно выполненная программа на РНР работает с большим (содержащем 400 тыс. с лишним строк) файлом ненамного медленнее, чем аналогичная программа на С: всего в 3…5 раз. Но, не на порядки, как ни странно.

Для ускорения поиска информации базы данных дают возможность ее индексирования. Конечно, при использовании файлов вместо баз данных придется реализовывать механизмы индексирования как-то самостоятельно. Можно также кэшировать файлы в оперативной памяти сервера, и т.п. Что может привести к существенным затратам труда и времени на разработку. Однако, как видится, в серьезных проектах – оно того стоит. Вместо того, чтобы каждый раз рисковать и переживать – а ВСЕ ли ошибки устранил разработчик базы данных, или нет. Ведь отвечать ЗА СЕБЯ как-то надежнее, чем за себя и еще ЗА РАЗРАБОТЧИКА базы данных.

Предпроцессоры CSS

После того, как освоен бэкенд, можно перейти к изучению предпроцессоров CSS. Наиболее популярными среди них являются Sass и Less. В двух словах, эти предпроцессоры позволяют динамически (на лету) формировать файл CSS и сразу же выдавать его клиенту-браузеру. Это бывает необходимо, когда следует по каким-то причинам изменять содержимое файла CSS. Например, выполнять разное оформление вебстраницы в зависимости от IP-адреса пользователя. Также данные технологии используются, чтобы ускорить создание файла css.

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

Вместо этой технологии вполне можно делать ТО ЖЕ САМОЕ при помощи серверного языка программирования (например, PHP или С) или же осуществлять рендеринг страницы на клиенте средствами javascript (посылая разные коды javascript в зависимости, например, от IP-адреса). Ибо последний предоставляет вполне достаточный интерфейс по управлению правилами CSS.

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

В целом

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

  • html,
  • CSS,
  • javascript (или его аналог),
  • серверный язык,
  • базы данных (опционально),

можно считать, что Вы более-менее способны на серьезное сайтостроительство. Когда же человек что-то ухватил из области языка html (путем прочтения пары десятков статей из интернета, но, не ознакомившись с серьезной литературой и практикой), научился создавать файл с расширением .css, а также научившийся устанавливать на сервер какую-нибудь CMS и плагины/библиотеки к ней – такой человек решительно не может считаться вебпрограммистом. Именно про таких и сказана пословица: «вебпрограммист – это диагноз». Именно такие потом, после нескольких лет работы «вебпрограммистами», начинают вдруг жаловаться на форумах на то, что, мол надоела им эта профессия, воротит их от нее «почему-то».

Надеюсь, понятно – почему? Да потому, что без освоения базы – человек сразу приступил к высокоуровневым вещам – CMS, библиотекам и т.п. Без освоения языка javascript человек, выбрав легкий путь, практически СРАЗУ начал использовать jQuerry, Bootstrap и т.п. И ему все показалось каким-то легким и даже интересным… Однако, это – ровно до того момента, пока не встретилось нечто, хоть мало-мальски требующее более углубленных знаний и умений, что не слишком хорошо поддерживает его «излюбленная» библиотека. Встретилось подобное – раз, два, три… и человек, естественно, не справляясь с работой, рано или поздно начинает испытывать недовольство. Вместо того чтобы, наконец-то, взять дельную литературу и поработать над ней месяц… полгода…год, человек начинает троллить на форумах, обсуждая, нередко, всякую ерунду. Нередко – корявым языком и терминологией. Но, дела-то от этого не двигаются… В итоге, человек остается, что называется, при «сухом остатке». Недаром программисты, видавшие кой-чего, дают советы по выявлению «диагноза»: предложите, мол, человеку написать клиентский код на вебстранице без jQuerry, на чистом javascript. Если он обладает вышеуказанным «диагнозом», то тут же откажется, ссылаясь на что угодно; например, на «непонимание» «современных высоких технологий» заказчиком. Такая вот, моментальная (как фото) проверка квалификации.

Ну, а дальше – изучаем настройки сервера

Надо сказать, что, на самом деле, развитие вебпрограммиста еще не закончено. Ему бы, как минимум, изучить хотя бы азы работы с сервером. Например, если речь идет о Linux-хостинге с установленным на нем сервером Apache, то необходимо, как минимум, изучить основы файла .htaccess.

Обратите внимание, файл этот НЕ ИМЕЕТ имени, присутствуют только точка и расширение.

В этом файле содержатся общие настройки хостинга. Например, управляющие доступом к файлам из конкретного каталога – быть может, в зависимости от вида клиента или его IP-адреса. Или – указание на то, как обрабатывать ошибки и иные сообщения сервера при запросах к нему (например, ошибку 404 – «ресурс недоступен»). На самом деле, в этом файле может содержаться множество различных настроек, указывающих серверу – как обрабатывать файлы и каталоги сайта.

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

Кстати, для того, чтобы использовать все возможности многообразия настроек файла .htaccess, необходимо хорошо знать синтаксис РЕГУЛЯРНЫХ ВЫРАЖЕНИЙ. Вкратце, это – технология, позволяющая автоматически заменять одни (заданные) сочетания символов некоторой строки другими (тоже заданными) сочетаниями символов. Регулярные выражения используются во многих языках программирования, в том числе в С, РНР, Питоне, javascript, Java, Ruby и т.д. - для обработки строк. Так вот, они же применяются и в файле .htaccess.

Как правило, регулярные выражения вызывают сильные затруднения у начинающих в силу их особенного синтаксиса. А также, как это ни странно, в силу ОТСУТСТВИЯ в интернете серьезных и детальных материалов на эту тему. Те материалы, что, к примеру, нам удалось видеть, представляли собой лишь отрывочные, фрагментарные сведения, зачастую – без надлежащего детального объяснения. И, дай бог, если раскрывающие хотя бы какой-нибудь один небольшой вопрос. Ну, а серьезную, хорошую книгу по регулярным выражениям и по настройке сервера приобретет не каждый «вебпрограммист». Потому-то настройка работы сервера при помощи файла .htaccess для многих представляет как бы «темный лес». Хотя, если разобраться, на самом-то деле ничего сверхсложного в регулярных выражениях нет.

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

Также следует знать хотя бы основные настройки языка программирования. Если это – PHP, то для настроек имеется файл php.ini (на большинстве хостингов). Впрочем, там, как правило, имеются оптимальные, для конкретного сервера, настройки. Поэтому менять их обычно нет необходимости.

На самом деле, освоение файлов .htaccess и php.ini относится больше уже к администрированию сервера, чем к вебпрограммированию. Однако, некие начальные вещи должен знать каждый вебмастер.

То же можно сказать и про остальные предметные области, идущие на схеме ниже (они обрамлены прямоугольником зеленого цвета). Указанные предметные области касаются освоения работы высокоуровневых протоколов, в первую очередь, HTTP, HTTPS. Ведь в процессе получения страницы и взаимодействия, браузер с сервером обмениваются различными заголовками. Сообщения таких заголовков целесообразно уметь понимать и, в необходимых случаях – изменять для того, чтобы добиться требуемой функциональности сайта.

Протокол SSH необходим для того, если вебмастеру необходимо зайти на сервер Linux через консоль (для Windows есть специальные программы для аналогичных целей, например, клиент Putty). Дело в том, что иногда через консоль гораздо удобнее, да и быстрее взаимодействовать с сервером, нежели, скажем, через клиент, работающий по протоколу FTP. Например, Вам может понадобиться определенным (одинаковым) образом переименовать файлы в том или ином каталоге Вашего хостинга. Или – запустить на нем соответствующую программу-утилиту.

Несколько особняком стоит (см. схему) последняя отмеченная область –  транспортные протоколы. Коль скоро зашел о них разговор, то понятно, что речь идет о языках типа С/С++. ТСР/UDP-клиенты позволяют соединяться и взаимодействовать с сервером, не используя высокоуровневые протоколы типа HTTP. В подавляющем большинстве случаев для вебпрограммиста это не нужно.

Вообще, например в языке РНР есть так называемые вебсокеты, но они не имеют отношения к обычным сокетам, которые функционируют на основе транспортных протоколов.

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

Заключение

Вот такая схема – динамика познавательного процесса обучения вебпрограммированию. Надеемся, понятно, что для того, чтобы освоить более-менее качественно хотя бы основные моменты, перечисленные выше, понадобится, как минимум, 1…2 года ежедневного(!) изучения, не отвлекаясь на иное. Если говорить об обучении где-нибудь в университете/институте, то этот процесс будет растянут на гораздо более длительный срок, ибо помимо указанных областей, там будут изучаться и совсем иные, не имеющие отношения к вебпрограммированию, дисциплины. Однако, в любом случае, даже и в учреждениях высшего образования, даже при суперкачественном преподавании, если студент не будет заниматься (очень-очень много) самостоятельно, ни о каком мало-мальски серьезном уровне вебпрограммирования мечтать не приходится.

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

Скажем, работа бухгалтера, экономиста, типичного юриста или начальника буровой нефтяной вышки – в этом смысле гораздо-гораздо проще. И это следует иметь в виду человеку, решившему начать СЕРЬЕЗНО программировать в веб.

Ну, а, повторимся, недопрограммисты, узнавшие, что, оказывается, есть такой тег <html>, а также научившиеся делать вызовы функций из библиотек типа jQuerry и, быть может, устанавливать CMS – таких «программистов» масса. Как масса и «юристов» (не умеющих даже составить аргументированное исковое заявление), «менеджеров» (идущих в итоге работать в Metro или Ikea - продавцами), «экономистов» (считающих, с подачи СМИ, что в России курс доллара зависит от цен на нефть и троллящих об этом в сети), «нефтяников» (затрудняющихся в условиях санкций, без применения западных технологий, даже обслуживать газопроводы, не говоря уже об их масштабном производстве), ну, и т.д.

На мой личный взгляд, подобные программисты «с диагнозом» - знаете, для чего нужны? Лишь для массовости. Представляющей своего рода аналог митинга, только длящегося непрерывно. Крупные компании (типа Google, Microsoft, Mozzilla… и многочисленный ряд других) заинтересованы в разжигании ажиотажа вокруг интернета. Чем больше будет людей, так или иначе связанных с интернетом, в том числе, и с вебпрограммированием – тем больше ажиотаж и, соответственно, в итоге – тем больше доходы компаний.

Собственно, аналогичный ажиотаж пытаются разжечь, например, вокруг операционной системы Linux. Не, ну, система-то неплохая, в целом – надежная; стоит основательно изучить миллионы строк исходного кода – и все, можно самому переделать, сделать под себя. Она даже предустанавливается на некоторые новые компьютеры (ноутбуки, планшеты). Но – гораздо менее удобная, чем известная Windows. Хотя, для технических(!) целей – например, для обслуживания интернет-хостинга или суперкомпьютера – донельзя подходящая. Ведь не зря именно она установлена на 96% суперкомпьютеров мира и на 75% хостингов. Собственно, потому-то ее и применяют, чаще всего, лишь в технических целях указанного вида. Как только станет удобной – так получит распространение и среди массовых пользователей.

Кстати, я, автор настоящей статьи, вовсе не против Linux (или Windows, впрочем). Просто - надо смотреть правде в глаза. А она состоит в том, что в Windows многие настройки предоставляются "из коробки", а в Linux приходится "конфиги править" и/или выполнять что-то типа sudo apt-get install ....
Linux сильна своей консолью (но, извиняюсь, помнить эти десятки-сотни разных консольных команд для каждого случая, это, так сказать, "на любителя"; все-таки, гораздо проще и БЫСТРЕЕ нажать на кнопку, чем держать в памяти эти команды и набирать их в консоли). И, вроде бы, надежностью. Хотя - все относительно.

Да – лишь для массовости. Ведь сколько-нибудь серьезные-то сайты все равно делают – другие люди. Те, число которых раз в 100…1000 раз меньше. А раз так – стоит ли обсуждать, скажем, такие вещи, как заработная плата «программиста с диагнозом»? Или - рынок труда для него? В самом деле, ведь на митингах-форумах (ну, там – где массовость) денег-то не платят. Там – лишь ажиотаж и, в силу незнания базовых вещей - троллинг, нередко. А если и платят – так это как-то... Да и мало, в любом случае.

Так что тем, кто решил стать вебпрограммистом, следует, видимо, определить для себя: способен ли (а, главное – захочет ли!... Ведь дорогу освоит - идущий; главное - ИДТИ в правильном направлении) он(а) освоить обрисованную выше, столь массивную, совокупность знаний. Как минимум, три-четыре языка программирования, плюс к тому – опционально, по необходимости – разные технологии: фреймворки, библиотеки, CMS. Или человек в итоге станет «как все», т.е. чему-то где-то там научится и, не имея реальной подготовки, базы - будет считать, что, мол, делает «готовые информационные продукты». За которые его(ее) будут периодически ругать, но он(а) все равно будет стоять на своем и думать, что, мол, «сайты делает».

Вот что мы можем сделать для Вас:
Интересная и полезная
информация
Изменить размер шрифта:
?