Пишу свои мысли о web-разработке и о жизни. Работаю в веб-студии Феникс — phoenix-cg.ru Связаться со мной можно по почте viktor@koreysha.ru
12 заметок с тегом

программирование

Ctrl + ↑ Позднее

Гиковский сайт

3 марта 2016, 14:48

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

Представляю вашему вниманию мою первую попытку. Буду рад отзывам, замечаниям и предложениям.

web   программирование

Как мы вводили git

15 января 2016, 22:10

Git — это одна из популярных систем контроля версий. Код — это, прежде всего, текст. Такой текст, который правят многократно и по чуть-чуть в разных местах. Хранить только последнюю версию кода не дальновидно, по тому, что часто какие-то правки приходится отменять, а в каких-то случаях надо посмотреть «как оно работало раньше». Хранить каждую новую версию кода, то есть копировать всю директорию, допустим раз в день, не удобно по двум причинам: во-первых, занимает много места, а во-вторых, не дает никакого понимания о том, что именно изменилось.
Умные программисты придумали решение этих проблем. Оно заключается в том, что бы хранить какую-то базовую версию, а после сохранять только маску изменений. Например, мы храним 1000 строк кода и после изменений запоминаем, что поменялись 387 строка и 425.
Такое решение дало еще один неожиданный плюс. Оно позволило работать над одним и тем же кодом разным людям одновременно. Первый программист поменял вторую, третью и четвертую строку, а второй — девятую и десятую. Система сама поняла, что может применить к начальному коду и те изменения и эти. И только, если возникнет конфликт, придется разруливать людям.

Америка

Впрочем, если вы так или иначе связаны с разработкой программного обеспечения, скорее всего, Америку я вам не открыл. Во всем мире различные системы контроля версий — неотъемлемый атрибут любого программиста. Читая профессиональные форумы, блоги известных web-разработчиков и доклады с различных конференций сложно себе представить, что кто-то может жить без git-а или svn-а. Однако, в наших реалиях куча небольших веб студий и одиночек-фрилансеров работают «по-старинке». Так получилось, что и я на первых своих местах работы с системами контроля версий познакомился только заочно. До сих пор стыдно признаться, что несколько лет я писал код без таких систем.
Впрочем, я был такой не один. И так получилось, что у нас собралась команда из четырех человек, где никто полноценно с контролем версий не работал. У меня был до этого опыт, где все настроили до меня и оставалось только коммитить, то есть записывать изменения которые я внес. Еще у двоих членов команды был подобный опыт. Однако никто из нас не представлял, как полностью должна работать система от компьютера программиста до «боевого сервера».

Как ни странно, гугление не могло ответить на те вопросы, которые возникали у меня в первую очередь. Например гугл на вопрос «Как смержить ветки git» дает около 700 результатов и вся первая страница по делу. А на запрос «git локально или на сервере» дает 275 тыс ответов и я не смог найти что-то в тему.

Наши правила

Многое мне было непонятно. Но в итоге чтения кучи статей и советов я принял ряд решений.

  1. Мы отказались от гита локально на каждом компьютере разработчика. Вместо этого, мы используем IDE и копию проекта на нашем сервере. У каждого разработчика есть своя локальная копия и своя удаленная копия. Уже на сервере стоит гит и туда надо зайти что бы провести с ним какие-то операции. Такое решение я принял по целому ряду причин. Основная причина в том, что мы взяли курс на проекты выше среднего по сложности и настраивать у каждого разработчика веб-сервер с нужными пакетами в условиях разных ОС и различной удаленности друг от друга сложная задача. А внедрить все это надо было без ущерба для производства.
  2. Никаких встроенных в IDE систем поддержки git и других «улучшителей вкуса» мы решили не использовать. Во-первых, в нативных командах из консоли нет ничего, чему нельзя научить за пару дней. А во-вторых, меня однажды такая система поддержки сильно подвела — вывела совсем не то, что произошло на самом деле.
  3. Мы ввели правило одна задача — одна ветка. Коммитов в нее может быть много, но чаще 1-2. Сливаем изменения только после завершения задачи.
  4. Все, что не касается напрямую нашего кода мы стараемся исключить из системы контроля версий. С этой задачей до сих пор справляемся хуже всего.
  5. Ввели правило «сервера для тестирования». Каждый раз после сливания изменений от разных разработчиков сайт поступает на тестирование и только потом выходит в продакшн, как бы не торопил заказчик.
  6. Мы стали использовать git в связке с Bitbucket. Система контроля версий без удаленного репозитория и в половину не так хороша. Но это, наверное, тема для отдельной заметки.

И все пошло, как по маслу?

В начале было очень тяжко. Постоянно забывали новую схему работы и то вносили какие-то правки прямо на «живом сервере», то забывая про это пытались залить туда изменения с сервера разработки. Постоянно получали конфликты и не понимали, как их решать. Самое сложное было постоянно заставлять всех работать только через систему контроля версий. Каждый раз хотелось «сделать последний разок по-простому». И каждый раз приходилось останавливать и себя и команду.

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

А какую систему контроля версий используйте вы? И какие сложности были с её внедрением?

web   программирование   управление

Роутер, как компонент веб-системы. Часть 1.

5 января 2016, 18:48

Я продолжаю разбирать разные компоненты CMS. Предыдущие заметки по теме:

Любая страница сайта доступна по какому-то адресу (URL). Бывает, конечно, что у одной и то же страницы несколько адресов. Или наоборот, при какой-то динамической погрузке контента, в итоге пользователь по одному и тому же адресу увидит разные страницы (Что является грубой ошибкой, но ою этом как-нибудь потом). Но в целом какое-то соответствие адреса и страницы есть всегда.

К радости начинающих и ленивых разработчиков, это соответствие уже работает на стороне web-сервера. Сначала, он с помощью механизма Виртуальных Хостов определяет корневую директорию сайта и сам ищет в ней фаил index, который и становится главной страницей. Потом, каждой папке dir ставит в соответствие адрес mysite.ru/dir/. Для простых сайтов без сложной внутренней архитектуры этого вполне достаточно.

Что же не так?

Но при построении CMS возникает ряд сложностей с такой системой:

  1. Хочется из административной панели управлять URL-ами. А это значит, надо дать возможность оттуда создавать и удалять папки. Это не безопасно давать администратору сайта такие серьезные права на сервере. С ними он может снести весь сайт. А право управления URL фактически приравняется к праву администратора сервера.
  2. Перенос кода из одних папок в другие сильно осложнит разработчикам жизнь. Такая неразбериха противоречит идеям контроля версий кода. Кроме того, усложняет задание относительных путей внутри системы.
  3. Код разбросанный по разным папкам по принципу отношения к разделам, прямо скажем, очень плохое архитектурное решение. Нам важно минимизировать дублирование кода и упростить разработчикам поиск места «где считается вот-такая-вот циферка». И та и другая задача решены в этом случае крайне плохо.
  4. URL должен быть удобен для пользователя и понятен поисковым роботам, а внутренняя система директорий должна быть удобна и понятна разработчикам. Нет никакого смысла усложнять жизнь одним, в угоду других. Этот пункт частично пересекается с предыдущими, но думаю, что его стоит выделить.

Все эти сложности и, возможно, еще какие-то заставили разработчиков искать выход. Я наблюдал в разных системах несколько вариантов таких выходов. Принципиально можно выделить два подхода.

В каждой папке подключаем ядро

Оставляем маршрутизацию на совесть web сервера, но отказываемся от кода внутри каждого раздела. Все, что мы делаем — это запоминаем что это за раздел (например записываем его ID) и дальше подключаем «ядро системы», которое уже обрабатывает запрос, готовит контент и т. д.
В этом случае внутри папки about будет примерно такой код:

$section = '22';
include('/includes/core.php');

А вся остальная система уже разворачивается из core.php.

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

Минусы в том, что пользователь все-же из административной панели управляет созданием и удалением папок. Это может привести к трудноуловимым ошибкам. Например, если администратор сайта создаст раздел lib, а у нас есть такая папка и она содержит важные для нас библиотеки, то либо он её удалит и прекратит работать вообще все, либо не сможет создать раздел и опечалится.

Единая точка входа

Более распространенный в крупных системах вариант — это единая точка входа. Тут основная идея простая. Что бы не запросил пользователь мы должны всегда отправить его в один и тот же фаил, где уже разобрать его запрос и решить какой контент стоит отдать. Обычно при таком подходе вариант по умолчанию все равно остается и помогает подключать скрипты картинки и т. д. Но для основных адресов сайта паки не создаются. Вместо этого мы так настраиваем наш web-сервер, что бы при невозможности найти папку мы всех отправляли в единый фаил. А в нем уже решаем валидный это адрес для нашей системы или надо отдать какую-нибудь ошибку.
Вот пример простого .htaccess для такого подхода:

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^.*$ /core.php [NC,L]

Тут написано, что если ни фаил ни дириктория не найдены, то отправлять все в core.php.

Главный плюс такого подхода — бОльшая гибкость. Ну а минус — сложности при переносе на дешевые хостинги.
Отдельно хочу отметить, что этот подход очень хорошо сделан в Yii фраемворке. Все файлы, которые нужно находить «встроенной» навигацией находятся в папке public, а все «внутренности» в отдельной папке protected. Такое распредление позволяет достаточно безопасно настроить права доступа.

#После точки входа
В обоих подходах всегда есть общая точка входа. И у же в ней идет формирование того, что мы отдадим пользователю. Как правило эта точка входа построена в два этапа. В первом этапе подключаются и инициализируются срикпты, которые должны работать на сайте всегда, не зависимо от того, куда хотел попасть пользователь. Это, например, подключение к базе данных.
А второй этап, как правило, зависит от того, что запросил пользователь. Конечно, можно прописать в ядре какой-то гигантский оператор switch и при добавлении каждого нового функционала дописывать к нему опции. Но это подход человека, который не слышал об архитектуре приложении. Более же правильный путь — создать набор модулей. И по надобности подключать тот или иной модуль. Именно так устроены большинство CMS и фраемворков.
В таком случае нам понадобится блок в коде, который принимает запрос и решает какой или какие модули нужно подключить. Именно этот блок и называют Роутером или по-русски Маршрутизатором.

Уф. Большое получилось вступление. Пожалуй, остановлюсь тут и продолжу во второй части.

web   программирование

Новогодний снежок на сайт

24 декабря 2015, 22:27

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

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

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

Результат

Процесс

Эта часть для тех, кто только изучает джаваскрипт. Всем остальным, думаю, будет не очень интересно.
Все, что нам понадобится в HTML, это canvas с идентефикатором snow. И я запустил скрипт по событию на BODY onload=«init()». Это не лучшее решение, но оно за рамками самого «снега», так что оставлю его на совесть того, кто будет код использовать.
Весь наш код состоит из четырех функций.
function init() — тут мы делаем подготовку к запуску и запускаем. В этой функции должны быть все операции, которые нужно произвести до основного кода.
function draw() — отвечает за отрисовку текущего состояния снега.
function update() — отвечает за установку нового состояния. Оно будет отрисовано на следующем шаге.
function mousemove(event) — отвечает за отслеживание положения мыши. Эту функцию я добавил по тому, что захотелось какого-то интерактива. Снег не должен всегда падать только вниз, в жизни его сдувает ветром то туда, то сюда. Я решил, что за ветер будет отвечать курсор. Чем дальше он от центра экрана (горизонтално), тем сильнее ветер в эту сторону. Если интерактив не нужен, то от этой части можно отказаться.

Подробнее

Начну разбор с инициализации. Для начала я накидал что-то подобное:

function init() {
  //Canvas init
  var canvas = document.getElementById('snow');

  //Canvas resize
  var W = window.innerWidth;
  var H = window.innerHeight;
  canvas.width = W;
  canvas.height = H;

  //Get context
  var ctx = canvas.getContext('2d');
  ctx.strokeStyle = 'white';

  //Prepare array of particles
  var mp = 100;
  var particles = [];
  for (var i = 0; i < mp; i++) {
    particles.push({
      x: Math.random() * W,
      y: Math.random() * H,
      r: Math.random() * 3 + 1
    })
  }
}

Первые три блока можно скопировать из любого «Самоучителя по Canvas для чайников». Получаем конвас, растягиваем на всю страницу и готовимся рисовать белым цветом.

В последнем блоке создаем массив, который будет отвечать за снежинки. Particles — массив снежинок. А каждая снежинка это объект, который «помнит» о своих координатах и диаметре. Для каждой снежинки задаем её начальное состояние: она должна быть где-то на нашем канвасе (случайным образом) и должна получить диаметр от 1 до 4 пикселей.

После этого переходим к отрисовке текущего состояния нашего снега.

function draw(W, H, particles, mp, ctx) {
  //Clearing
  ctx.clearRect(0, 0, W, H);

  //Set white whith opacity 0.8
  ctx.fillStyle = «rgba(255, 255, 255, 0.8)»;

  //Drowing
  ctx.beginPath();
  for (var i = 0; i < mp; i++) {
    var p = particles[i];
    ctx.moveTo(p.x, p.y);
    ctx.arc(p.x, p.y, p.r, 0, Math.PI * 2, true);
  }
  ctx.fill();
}

Тут то же все просто. Чистим поле и заново рисуем каждую снежинку на её координатах и с её диаметром. Для новичков хочу обратить нимание, что мы сначала «накидываем» все в контакст. И только один раз отрисовываем с помощью ctx.fill();

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

function update(W, H, particles, mp, ctx) {
  for (var i = 0; i < mp; i++) {
    var p = particles[i];
    p.y += 1 + p.r/2;

    if (p.y > H) {
      particles[i] = {
        x: Math.random() * W,
        y: -10,
        r: p.r
      };
    }
  }
}

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

Когда мы все это подготовили нам осталось запустить отрисовку по таймеру. Для этого добавляем в init:

setInterval(function() {
    draw(W, H, particles, mp, ctx);
  }, 50);

И после отрисовки сразу общитывать новое состояние. Для этого вызываем update в конце draw:

update(W, H, particles, mp, ctx);

Интерактивчик

Все. Простой снег готов. Но мне захотелось добавить интерактива. А то никакого профита, что налету снег обсчитываем. Добавляем функцию, которая отслеживает движения мыши и всгда записывает её положение. Для записи я расширил объект body, который точно есть у нашей веб-страницы. Добавляем в init:

document.body.myData = {
    x: 0,
    y: 0
  };
  document.onmousemove = mousemove;

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

function mousemove(event) {
var mouse_x = mouse_y = 0;
if (document.attachEvent != null) {
mouse_x = window.event.clientX;
mouse_y = window.event.clientY;
} else if (!document.attachEvent && document.addEventListener) {
mouse_x = event.clientX;
mouse_y = event.clientY;
}
document.body.myData.x = mouse_x;
document.body.myData.y = mouse_y;
}

Отследить то мы отследили. Осталось добавить скорость вдоль горизонтальной оси Ox:

var speed_x = (document.body.myData.x — (W / 2)) / W;

Смотрим в какой половине мышь: в правой или левой. И как далеко она от центра. Чем дальше, тем «сильнее ветер».

И осталось добавить сдвиг по Ox:

p.x += speed_x * 10;

Вместо послесловия

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

web   программирование

Шаблонная система

20 декабря 2015, 0:36

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

После того, как фронтенд-разработчики выдали готовую верстку, а бекэнд-разработчики построили систему взаимодействия с базой данных, наступает момент, когда необходимо указать системе какую информацию она должна брать и куда вставлять. Эту операцию иногда называют «повесить на админку». Конечно, я утрирую, и далеко не всегда это делается после всех остальных работ, а не вперемешку с ними. Но для нас сейчас это не важно. А важно то, что такая операция существует и её цель построить однозначные связи между информацией полученной или сгенерированной бекэндом и отображением для пользователя.

PHP, как шаблонная система

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

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

Такого метода придерживаются многие популярные CMS системы — WordPress, 1C-Bitrix, NetCat (частично) и другие.

Что в этом методе хорошего?

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

Что тут не так?

  • Велик соблазн вставить кусок логики в шаблон. Такие действия не пресекаются на уровне системы.
  • Больше мусора. Как минимум открывающий и закрывающий теги его создают.
  • Вывод в шаблон привязан к особенностям системы. Если мы поменяем функцию, то нам придется менять её и в шаблоне. Мы открываем свой «внутренний мир» тому, кто привязывает шаблон к бекэнду.
  • Если ошибка произойдет прямо в шаблоне то нам сложно будет её найти и разобрать. Это связано с тем, что часть страницы на тот момент уже выведется и мы можем на понять, что ошибка произошла перед каким-нибудь закрывающим тегом из-за чего у нас полная каша.

Отдельная шаблонная система

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

%title%

до блоков типа:

{foreach from=$myArray item=foo}
{$foo}
{/foreach}

При определенном идет таких договоренностей верстальщик может сразу сделать из HTML-верстки нужный шаблон для внедрения. Ну или по крайней мере подготовить его к этому. Это экономически целесообразно, хотя на практике целиком такое получается крайне редко. Такого подхода придерживатся: Umi.cms , Drupal(опционально), Symfony framework и многие другие проекты.

Что в этом методе хорошего?

  • Пропадает необходимость контролировать разработчиков по разделению логики представления от бизнес-логики. Используя «шаблонизатор» мы точно уверены, что никакая часть бизнес-логики не «просочится» в шаблон.
  • Шаблон в итоге выглядит чище. Это не абсолютное правило, но тенденция.
  • Мы можем разделить права. К примеру дать кому-то права изменять только шаблоны и мы будем уверены, что он не «докопается» до базы данных, например.

Что тут не так?

  • Меньше скорость работы. Однако, при использовании кеширования этот минут сходит на нет.
  • Требует отдельного изучения. Правда, как правило, структура шаблона достаточно простая для понимания разработчиками.

Вывод

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

web   программирование
Ctrl + ↓ Ранее