Иначе, если вы полностью отмените сделанные в файле изменения, то он пропадет из дифа этого коммита, и при повторном мерже с ним ничего не произойдет. Все будет так, как и было в целевой ветке до мержа. git merge будет говорить Already up-to-date, но содержимое файлов будет разным в этих ветках.

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

Притом это работает в любую сторону на уровне файла. Удалили строку в файле –> замержили куда-то –> вернули ту же строку в файл поменяв коммит –> замержили снова. Там где меняли строка есть, там куда мержили нет. Получается классическая ситуация: “А у меня на ноутбуке все работает, сами ищите что не так!”.

Погнали разбираться ну как так-то

Создадим репозиторий и в нем два файла:

1
2
3
4
5
6
7
8
9

/tmp/git_fuckup $ git init
Initialized empty Git repository in /tmp/git_fuckup/.git/
/tmp/git_fuckup $ touch correct.txt broken.txt
/tmp/git_fuckup $ git add .
/tmp/git_fuckup $ git commit -m "Init commit"
[master (root-commit) d2b04c9] Init commit
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 broken.txt
 create mode 100644 correct.txt

Создадим новую ветку, напишем что-нибудь в первый и второй файлы и замержим в мастер:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

/tmp/git_fuckup $ git commit -m "Init commit"
[master (root-commit) d2b04c9] Init commit
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 broken.txt
 create mode 100644 correct.txt
/tmp/git_fuckup[master] $ git checkout -b feature
Switched to a new branch 'feature'
/tmp/git_fuckup[feature] $ echo 'I need to be here!' >> correct.txt
/tmp/git_fuckup[feature] $ echo 'I need to be here!' >> broken.txt
/tmp/git_fuckup[feature] $ git add .
/tmp/git_fuckup[feature] $ git commit -m "Texts added"
[feature 551d298] Texts added
 2 files changed, 2 insertions(+)
/tmp/git_fuckup[feature] $ git checkout master
Switched to branch 'master'
/tmp/git_fuckup[master] $ git merge feature
Updating d2b04c9..551d298
Fast-forward
 broken.txt  | 1 +
 correct.txt | 1 +
 2 files changed, 2 insertions(+)

Проверяем, что все ок:

1
2
3
4
5
6
7

/tmp/git_fuckup[master] $ cat correct.txt
I need to be here!
/tmp/git_fuckup[master] $ cat broken.txt
I need to be here!
/tmp/git_fuckup[master] $ git log --oneline
551d298 Texts added
d2b04c9 Init commit

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

1
2
3
4
5
6
7
8
9

/tmp/git_fuckup[master] $ git checkout feature
Switched to branch 'feature'
/tmp/git_fuckup[feature] $ git checkout HEAD~1 broken.txt
/tmp/git_fuckup[feature] $ git commit --amend
[feature a12625d] Texts added
 Date: Wed Dec 13 23:09:53 2017 +0700
 1 file changed, 1 insertion(+)
/tmp/git_fuckup[feature] $ cat broken.txt
/tmp/git_fuckup[feature] $

Файл пуст, все как планировали. Внимательный читатель уже должен заметить, что вместо 2 files changed, 2 insertions(+) имеем 1 file changed, 1 insertion(+). Из дифа полностью пропал один файл, что логично, мы же полностью удалили то, что добавляли и теперь этих изменений не существует в новом коммите. Важное замечание, что при изменении коммита, всегда создается новый комит с новым хешем, это знание пригодится позже.

Мержим теперь в мастер:

1
2
3
4
5

/tmp/git_fuckup[feature] $ cat broken.txt
/tmp/git_fuckup[feature] $ git checkout master
Switched to branch 'master'
/tmp/git_fuckup[master] $ git merge feature
Merge made by the 'recursive' strategy.

Все смержилось, конфликтов нет. Казалось бы что все здорово, но:

1
2
3
4
5
6
7
8
9

/tmp/git_fuckup[master] $ cat correct.txt
I need to be here!
/tmp/git_fuckup[master] $ cat broken.txt
I need to be here!
/tmp/git_fuckup[master] $ git co feature
/tmp/git_fuckup[feature] $ cat correct.txt
I need to be here!
/tmp/git_fuckup[feature] $ cat broken.txt
/tmp/git_fuckup[feature] $

В мастере строка есть, в фиче нет. Чтобы понять, что происходит, надо вспомнить, как происходит мерж веток. При мерже ветки A в B, находится ближайший родительский коммит Y между ними и затем дифы всех коммитов от Y до А поочередно применяются в ветку B.

Посмотрим лог мастер ветки:

1
2
3
4
5
6
7

/tmp/git_fuckup[master] $ g log --oneline --graph
*   81825c7 Merge branch 'feature'
|\
| * a12625d Texts added
* | 551d298 Texts added
|/
* d2b04c9 Init commit

Посмотрим дифы коммитов, оригинального и измененного.

1
2
3
4
5
6
7
8
9
10
11
12
13

/tmp/git_fuckup[feature] $ g show a12625d
commit a12625df8415a45f84a018532e295f6c8421238f
Author: Andreww8xx8 <avk@8xx8.ru>
Date:   Wed Dec 13 23:09:53 2017 +0700

    Texts added

diff --git a/correct.txt b/correct.txt
index e69de29..c20dfcd 100644
--- a/correct.txt
+++ b/correct.txt
@@ -0,0 +1 @@
+I need to be here!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

/tmp/git_fuckup[feature] $ g show 551d298
commit 551d2989dc60290122d7853c3373b0e0e09757ce
Author: Andreww8xx8 <avk@8xx8.ru>
Date:   Wed Dec 13 23:09:53 2017 +0700

    Texts added

diff --git a/broken.txt b/broken.txt
index e69de29..c20dfcd 100644
--- a/broken.txt
+++ b/broken.txt
@@ -0,0 +1 @@
+I need to be here!
diff --git a/correct.txt b/correct.txt
index e69de29..c20dfcd 100644
--- a/correct.txt
+++ b/correct.txt
@@ -0,0 +1 @@
+I need to be here!
/tmp/git_fuckup[feature] ±

При втором мерже git пытается накатить диф коммита a12625d. В нем только одно изменение в файле correct.txt и оно не конфликтует с тем, что есть в файловой системе после коммита 551d298, а про файл broken.txt в диффе a12625d ничего нет, поэтому он тоже останется таким как был в 551d298.

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

Работает так:

1
2
3

8xx8@mac ~/git-minus[master] $ cd /
8xx8@mac / $ cd -
8xx8@mac ~/git-minus[master] $

Некоторые знают о том, что git поддерживает похожее поведение при смене ветки:

1
2
3
4
5
6
7

8xx8@mac ~/git-minus[master] $ git co feature
Switched to branch 'feature'
8xx8@mac ~/git-minus[feature] $ git co -
Switched to branch 'master'
8xx8@mac ~/git-minus[master] $ git co -
Switched to branch 'feature'
8xx8@mac ~/git-minus[feature] $

Здесь я использовал алиас co для checkout. Вообще про алиасы у меня была отдельная статья.

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

На этот варанант я натолкнулся совсем случайно. Мы используем git-flow и названия веток у нас, как результат, длинные. Сливать свои изменения в staging приходится достаточно часто, вот и я подумал, а как так сделать, что бы поменьше делать.

1
2
3
4
5
6
7
8
9
10
11
12
13

8xx8@mac git-minus[feature/coll_stuff] $ git commit -m "second"
[feature 8f65d91] second
 1 file changed, 0 insertions(+), 0 deletions(-)
  create mode 100644 2
8xx8@mac ~/git-minus[feature/coll_stuff] $ git co staging
Switched to branch 'staging'
8xx8@mac ~/git-minus[staging] $ g merge -
Updating a2c0a4d..8f65d91
Fast-forward
 2 | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 2
8xx8@mac ~/git-minus[staging] $

PROFIT!

Для своего любимого редактора я долгое время использовал плагин Ack. Он обладает рядом багов, но в целом пользоваться можно.

Недавно я наткнулся на его форк Ag. Зацепило в нем две вещи:

• строка поиска сохраняется в регистр поиска;
• наличие комманды AgFromSearch, которая позволяет искать то, чтобыло в регистре поиска.

Эти факторы позитивно влияют на продуктивность.

В найденом файле все вхождения будут подсвечены (ну если включен hlsearch), и по нему сразу можно будет перемещаться с помощью n или N.

Если нужно поискать слово из текущего файла, нажимаем на этом слове * и выполнив :AgFromSearch без параметров сразу получаем результат.

Так же интересной показалась команда :AgFile, для поиска файла по имени.

Ну и как бонус, две буквы набирать проще трех.

Установка плагина не доставит хлопот, если вы используете Vundle , достаточно вписать в ваш .vimrc:

1

Bundle 'rking/ag.vim'

Из настроек я посчитал необходиммым:

1
2
3
4
5

  " Конфиг для вызова ag
  let g:agprg = 'ag --nogroup --nocolor --column --smart-case'

  let g:aghighlight=1 " Подсветить поиск
  cabbrev As AgFromSearch " Псевдоним чтобы меньше писать

Коммит с изменениями в моем репозитории.

— Ты дочитал книгу про Vim?
— Нет.
— А идеальный питч?
— Нет. Только половину.
— Эх, ну ты и читатель!

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

Такое положение дел меня не устраивает.

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

Тут можно провести четкую аналогию со спортивными трекерами. Принцип мотивации тот же. Хочу Endomondo, только для чтения.

Что помогло бы мне:

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

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

Второе могут предоставить различные программы для чтения или же электронные книги. Но я чаще читаю печатные издания. Хотя и для них есть интересный девайс http://www.mark-my-time.com/

Социальную составляющую может отчасти удовлетворить goodreads или imhonet, но там нет статистики, можно видеть только факт прочтения или не прочтения.

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

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

• авторизоваться в сервисе через удобную cоциальную сеть;
• выбрать, что он будет читать;
• записывать, на какой странице остановился после очередного чтения.

Так вот вопросы сообществу:

• Может быть уже есть то, что отвечает моим желаниям, и вы этим пользуетесь?
• Нужен ли такой инструмент кому-нибудь кроме меня?
• Кто-нибудь хочет помочь запилить это как-нибудь на выходных?

Ответы пишите в комменты. Репосты в социалочки буду расценивать как голос за то, что идея имеет право на жизнь и ее надо воплощать.

1
2

cat ~/.zsh_history | wc -c
431403

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

Не знаю как вам, а я думаю, это много. Даже если учесть, что половину из этого занимают пути к файлам и части, дополненные автокомплитом, это все равно много. Статистика взята примерно за 4 месяца, и если выкинуть выходные и прикинуть, получается около 6000 знаков в день. Пара страниц формата А4. Большая часть этого труда – это рутинные команды или последовательности типичных действий.

Как ни странно, но это одна из немногих ситуаций в жизни, когда можно делать минимум, а результата получать максимум.

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

Погружение на темную сторону можно разделить на несколько частей. Согласно сложности реализации и абстрагированности от реальной жизни.

Git

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

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

Полезные опции

Эти мелочи могут выручить всегда, даже если вашего dotfiles не будет рядом.

git log --oneline — Вывести лог в одну строку.

git add -u — Добавить в stage все, кроме файлов, находящихся вне git.

git status -s — Прагматичный статус без лишней информации.

git branch --merged — Ветки слитые в текущую.

git branch --no-merged — Ветки не слитые в текущую.

Базовые сокращения

1
2
3
4
5
6
7
8
9
10

cp = cherry-pick
st = status -s
cl = clone
ci = commit
co = checkout
br = branch

sl = stash list
sa = stash apply
ss = stash save

Diff

Изменения, приготовленные к коммиту (staged)

1

dc = diff --cached

Изменения в последнем коммите

1

dlc = diff --cached HEAD^

Изменения в определенном коммите (git dr dcee010)

1

dr  = "!f() { git diff "$1"^.."$1"; }; f"

Push / Pull

Применение изменений из векти так, чтобы все наши коммиты шли после

1

up = pull --rebase

Отправление только текущей ветки

1

put = push origin HEAD

Коммит

Отмена последнего коммита с сохранением состояния stage

1

undo = reset --soft HEAD^

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

1

aps = commit --amend -C HEAD

Определить нахождение коммита

1

where = branch -av --contains

Красивый лог

1
2
3

lg = log --pretty=format:\"%h %Cblue%ar %Cgreen%an%Creset: %s %Cred%d\"
ll = log -10 --pretty=format:\"%h %Cblue%ar %Cgreen%an%Creset: %s %Cred%d\"
gr = log --graph --pretty=format:\"%Cred%h %Cblue%ar%Creset %Cgreen%an%Creset %s%Cred%d\"o

А поможет ли вам задуматься над этим такая картина?

Наверное, поможет, особенно если увидеть это в ночь перед релизом. А началось-то все с того, что хотели фичу красиво слить через rebase.

Так давайте разберёмся, что пошло не так.

Гит пушит всё. Да, вы не ослышались. По умолчанию это так и есть. Беседы о том, что поведение по умолчанию не безопасное оставим за кадром и найдём решение.

1
2
3
4
5
6

$ git push --help
       git push [--all | --mirror | --tags] [-n | --dry-run]
[--receive-pack=<git-receive-pack>]
                  [--repo=<repository>] [-f | --force] [--prune] [-v |
--verbose] [-u | --set-upstream]
                  [<repository> [<refspec>...]]

Как видно из документации, мы можем пропустить указание назначения(repository) и refspec (конструкция вида ЛОКАЛЬНАЯВЕТКА[:][УДАЛЁННАЯВЕТКА]), по умолчанию в качестве назначения будет использовано origin, а в качестве refspec будет использована одна из стратегий определённых в настройке push.default. Она может принимать такие значения:

• nothing – не пушить ничего
• matching – пушить все ветки, названия которых в локальном репозитории совпадают с названиями в удалённом репозитории. Это как раз та опция, которая используется, если ничего не задано
• upstream – пушить только текущую ветку в ту ветку на удалённом репозитории, которая прописана в конфиге как upstream
• tracking – устаревший синоним для upstream
• current – пушить только текущую ветку в ту ветку на удалённом репозитории с которой совпадёт имя

Самый лучший способ решить проблему – это указывать repository и refspec всегда при выполнении команд push/pull.

Либо полностью:

1

git push origin branch:branch

Либо в качестве refspec использовать HEAD:

1

git push origin HEAD

В таком случае текущая ветка будет запушена в ветку с таким же названием в удалённом репозитории.

Можно сделать псевдоним для команды, чтобы было удобнее

1

git config --global alias.put 'git push origin HEAD'

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

1

git config --global push.default upstream

Началось всё с того, что мы стали замечать, что в master или в develop ветку начинают попадать коммиты из ветки staging. Самые распространённые из них — это мержи веток с задачами. Первый раз решили, что кто-то по невнимательности примержил стейджинг в ветку с задачей и потом вылил, разбираться точно как и кто не стали, просто всем ещё раз рассказали как нужно вести разработку и посоветовали внимательнее следить за тем, что они делают.

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

Разгадка проста и понятна сразу, кто-то примержил staging в ветку со своей задачей, а потом через некоторое время, когда она вышла в релиз, все нежелательные коммиты и попали в develop, а потом — в master. Но как? Если первый раз нам удалось найти злополучный коммит вида Merge branch staging into 'feature/fourth', то в последний раз во всей истории всё было чисто. Каждый участник команды говорил, что он всё делал по инструкции и по модели ветвления.

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

Мы имеем новый репозиторий с несколькими коммитами в master ветку и одним в develop

Далее создадим новую задачу(first), закоммитим в неё первый коммит и опубликуем.

1
2
3
4
5

$ git flow feature start first
$ touch first
$ git add first
$ git commit -m "First feature commit"
$ git flow feature publish first

То же самое сделаем для second

1
2
3
4
5

$ git flow feature start second
$ touch second
$ git add second
$ git commit -m "Second feature commit"
$ git flow feature publish second

Теперь менеджер попросил нас вылить вторую задачу на тестовый сервер:

1
2
3
4

$ git checkout -b staging
$ git merge feature feature/second
$ git merge feature/second
$ git push --set-upstream origin staging

Но, предположим, у нас произошла ошибка в приложении, связанная только с тестовым сервером и другого программиста попросили её исправить:

1
2
3
4

$ touch staging-fix
$ git add staging-fix
$ git commit -m "Staging fixed"
$ git push

Далее нас попросили вылить на тестовый сервер первую задачу. Для этого мы перешли в staging, обновили его и влили в него первую задачу:

1
2
3
4
5
6
7

$ git checkout staging
$ git pull --rebase origin staging
From github.com:Andrew8xx8/try_git
 * branch            staging    -> FETCH_HEAD
Current branch staging is up to date.
$ git merge feature/first
$ git push

Пока всё верно. От ветки develop сделаны две задачи. В ветку staging влиты обе ветки с задачами и есть ещё один коммит нужный только для неё.

Мы возвращаемся к разработке второй задачи, но нас кто-то отвлёк и случайно получается, что “на автомате из истории” мы вполняем такую последовательность комманд:

1
2

git checkout feature/first
git pull --rebase origin staging

И ничего вроде бы страшного не произошло, в дальнейшей рутине мы можем ничего не заметить. Так называемый мерж коммит не создался, потому что мерж прошёл в режиме fast-forward.

История, если бы в ней не было коммита Staging fixed, тоже сильно не изменилась.

1
2
3
4
5
6
7
8
9

$ git log --oneline
87bb177 Merge branch 'feature/first' into staging
dc4b6d6 Staging fixed
56351b4 Second feature commit
7b843ef First feature commit
f664597 Commit in develop
dfcf2d5 Removed all the cats
a0184dc Add all the octocat txt files
1aad731 Added cute octocat story

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

1
2
3
4

$ touch first-finish
$ git add first-finish
$ git commit -m "First feature finished"
$ git push

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

Хотя уже по графику видно, что произошёл некоторый факап, но когда веток и людей много этого незаметно, да и кто смотрит графики.

Затем нас просят выпустить первую задачу и сделать релиз, что мы и делаем:

1
2
3
4
5

$ git flow feature finish first
$ git push
$ git flow release start v1
$ git flow release finish v1
$ git push

Ну вот и всё. Полный фарш. В релиз попало то, что было в staging. В истории всё чисто с точки зрения того, что нет мерж коммита:

1
2
3
4
5
6
7
8
9
10
11
12

$ git log --oneline
5db05f9 Merge branch 'release/v1'
ffb5ee5 Merge branch 'feature/first' into develop
d93f812 First feature finished
87bb177 Merge branch 'feature/first' into staging
dc4b6d6 Staging fixed
56351b4 Second feature commit
7b843ef First feature commit
f664597 Commit in develop
dfcf2d5 Removed all the cats
a0184dc Add all the octocat txt files
1aad731 Added cute octocat story

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

1
2
3

87bb177 HEAD@{6}: rebase finished: returning to refs/heads/feature/first
87bb177 HEAD@{7}: checkout: moving from feature/first to 87bb1774e8d6555a06707a03ef1f0f9636206317^0
7b843ef HEAD@{8}: checkout: moving from feature/second to feature/first

Тоже ничего необычного.

Причина такого поведения — это fast-forward мерж. При таком слиянии в случае, если это возможно, указатель ветки просто перемещается на то же место, куда указывает ветка, которая вливается:

1
2

git checkout develop
git merge feature

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

Что делать чтобы такое не произошло?

Что делать, чтобы такое не произошло?

1. Внимательно следить за исполняемыми командами.
2. Если используется git-flow, то использовать его команды для обновления и публикации веток.
3. Использовать либо полный синтаксис команды git push/pull, либо полностью сокращённый синтаксис без указания веток. Потому что в ситуации из приведённого примера не указывается, в какую ветку слить изменения, поэтому так и получилось, что информация из staging попала в ветку с задачей.

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

Мечта? Нет. Реальность.

В кратце о технологиях

Markdown — облегчённый язык разметки. Первоначально создан Джоном Грубером (англ. John Gruber) и Аароном Шварцем, целью которых являлось создание максимально удобочитаемого и удобного в публикации облегчённого языка разметки

Keydown — Генератор HTML5 презентаций из Markdown кода.

Github::Pages — Хостинг статических сайтов, позволяет в один клик из Git репозитория сделать сайт опубликованный в вебе.

Рабочий процесс

Разберём как это делается на классическом примере Hello World!. Создадим презентацию из двух слайдов c текстом Hello и World.

Устанавливаем гем keydown

1

gem install keydown

Генерируем новую презентацию

1

keydown generate hello-world

Переходим в получившуюся папку и переименовывем slides.md в index.md, чтобы впоследствии упростить публикацию

1
2

cd hello-world
mv slides.md index.md

Любым удобным способом редактируем файл index.md, заменив всё что в нём на:

1
2
3
4
5
6
7
8
9
10
11
12
13

# hello-world

!SLIDE

# Первый слайд

## Hello

!SLIDE

# Второй слайд

## World

Генерируем слайды

1

keydown slides index.md

Идём на Github и создаём там новый репозиторий hello-world, затем из папки с презентацией выполняем следующие комманды подставив вместо <адрес_репозитория> адресс новго репозитория. Он должен выглядить типа: git@github.com:ВАШ_ЛОГИН/hello-world.git.

1
2
3
4
5
6
7

git init
git remote add origin <адрес_репозитория>
echo '.saas-cache' > .gitignore
git checkout -b gh_pages
git add .
git commit -m "Init commit"
git push -u origin master:gh-pages

Всё. Ждём. По адресу http://ВАШ_ЛОГИН.github.com/hello-world должна скоро появиться презентация.

В дальнейшем чтобы внести изменения

• Любым удобным способом редактируем файл index.md
• Генерируем слайды (keydown slides index.md)
• Коммитим, пушим

1
2
3

git add .
git commit -m "changes"
git push

Небольшая история о том, как я докатился до такой жизни.

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

Если кто-то еще не догадался, речь идет о ситуации на дорогах.

В нашем городе есть несколько способов узнать о том, что происходит на дорогах. Можно послушать радио (2х2 и Дорожное), можно посмотреть Яндекс.Пробки, а можно почитать ICQ бот. Каждый из них в чём-то хорош, но ни один из них не подходил в полной мере моему другу, заядлому микроблогеру, Дмитрию Вислову.

Неудобства были настолько заметными, что 20 сентября 2011 года ситуация достигла критической точки, и он с ещё двумя товарищами (Александром Щербининым, Костей Соколовым), пожертвовав законным перерывом на обед, сделал робота, который читает тот самый ICQ бот с информацией о дорогах и транслирует всё в специально созданный аккаунт @Ulway..

Идея пришлась по душе многим из нашего окружения, твиттер аккаунт быстро набрал около 200 подписчиков, в основном из друзей, знакомых, знакомых знакомых и т.д. Техническая сторона вопроса была достаточно тривиальной, скрипт читал по cronу бот, парсил содержимое, сохранял в базу для избежания дубликатов и отправлял в твиттер.

Через месяц успешной работы, основной разработчик начал свою хардкорную жизнь программиста и с головой ушёл в изучение Ruby/Rails. Какое-то время сервис поддерживали Юрий Токарев, Алексей Загайчук. Но затем в феврале 2012 года проект попал в мои руки. Попав в мои руки , скриптик сразу же был обёрнут в микрофреймворк Silex, что позволило немного упорядочить код.

Серьёзно к проекту никто не относился, работы в основном проводились в обед и редко. Да и зачем? Просто небольшое удобство в основном для себя и друзей, и так проект жил. К середине Марта 2012 года в подписчиках было около 350 человек, не такой уж и значительный рост за 4 месяца.

В среднем мы получали и публиковали 5-10 сообщений в сутки. Мало. Решили расширить список источников информации. Выбор пал на хештег #ulway. В нем обыватели нашего города иногда оставляли информацию о происшествиях. Там было не много материала, но хоть что-то. Схему работы придумали простую, раз в 10 минут PHP робот читает хештег, фильтрует мат и публикует от имени сервиса то, что должно пройти.

Неактивно, но пошла популяризация самого хештега #ulway.

Количество подписчиков начало расти. Из этого вытекало несколько задач:

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

Так появился ulway.net.

Мы торопились, хотели закончить к конференции “Стачка!”, поэтому бекенд было решено не переписывать.

Фронтэнд был написан на jQuery mobile. Мы хотели делать сразу приложение для мобильных телефонов, используя PhoneGap. Код был открыт, репозиторий и ныне на GitHub.

Бекенд всё так же остался на Silex, к нему лишь прибавился нехитрый алгоритм оценки “полезности” сообщения. Состоит он из частотного словаря, на основе которого высчитывается рейтинг сообщения, в случае, если оно проходит определённый порог, установленный экспериментальным путём, то сообщение считается подходящим. Частотный словарь подстраивается на основе того какие слова были в том сообщении, которое прошло фильтр.

К выступлению на “Стачке” фильтр и публикация сообщений работали. Сам доклад я пропустил, но он способствовал продвижению идеи в массы.

Моя светлая сторона умоляла начать делать всё “как надо”. Под впечатлением “Стачки” хотелось сразу писать на erlang. Задача казалось бы как раз для него! Но неделя глубокого исследования этого вопроса показала

• освоить erlang быстро с моим уровнем подготовки не получится;
• работа со строками в erlang это ад.

Объём быдлокода давил на моральные принципы, нужно было искать путь. И его, сам того не зная, подсказал Кирил Мокевнин. Вот тут.

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

Был использован Composer для управления зависимостями. В качестве основы остался Silex, но на этот раз я разобрался как работает Dependency Injection в нём. Был использован Simfony::Console для реализации взаимодействия с приложением через консоль. Для твиттера после долгих мучений подошёл лишь один пакет, но и его пришлось допилить.

Фронтенд был переделан на Twitter Bootstrap, но только его главная страница. Мы оба ленились переделывать саму форму с JQuery Mobile, на ней было много JavaScript лапши. Форма была взята из предыдущей версии и в таком состоянии “франкенштейна” это проработало ещё какое-то время.

Система работала достаточно стабильно. Подписчиков уже стало около 600. Люди стали активно публиковать свои сообщения.

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

Мы приняли решение бросить разработку текущей вресии и начать делать всё на рельсах. Причина крылась не в том, что это сейчас модно, а в том, что в инфраструктуре Ruby/Rails больше гибких, удобных инструментов для быстрой разработки веб-приложений.

После конференции RailsClub, которая проходила в нашем городе, мы пообщались с коллегами из Чебоксар, которым очень понравилась идея нашего сревиса и то, как он работает в Ульяновске. Они предложили свою помощь в популяризации в своём регионе. Идею также похвалили и ребята из http://evrone.ru/ С ними мы обменялись наклейкамми (Ulway на GistFolw) С этого же момента мы поняли, что приколюшка “для своих” вышла за рамки этого состояния. Ulway ­— это полноценный проект требующий больше сил и времени.

Нужно было придумать название для новой системы, которое бы отражало общее отношение к городам. Так и сошлись на Waytag.ru.

Следующий шаг, аренда VPS на Clodo и полное её администрирование через Chef.

Чтобы обеспечить быстрый и безболезненный переход в кратчайшие сроки уже на Rails, было сделана API модель, которая повторяла структуру старой базы. Старая система всё то, что отправляла в твиттер отправляла заодно и туда. Изменение базы данных в Rails осуществляется через специальные миграции, что позволило при переходе на новую версию просто их применить к существующей уже базе.

Сама архитектура системы усложнилась. Теперь нет скриптов которые по cron‘у читают твиттер. У нас работает комплекс процессов-демонов запущенных под runit, которые получают сообщения от твиттера через Twitter Streaming API, осуществляют их фильтрацию и публикацию, но уже через Twitter Rest API.

Так же появилась няшная админка, в которой можно посмотреть, поискать, отредактировать, создать всё то, что есть внутри нашей базы (прощай PhpMyAdmin!).

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

9 января 2013 года система окончательно была запущена. Все старые версии отключены.

Сейчас для Ульяновска в день публикуется около 15-30 сообщений, статистику за декабрь прошлого года можно заценить тут.

Мы таже присутствуем и в “офлайне” Иногда мы раздаём наклейки и футболки. Иногда всем подряд, иногда особо отличившимся, но обэтом лучше напишет Дмитрий Вислов.

В ближайшем будущем проект обретёт фирменный стиль, будет вести свой отдельный блог, обзаведётся поддоменами для городов, заново подружится с ICQ ботом и много чего ещё =)

Наш сайт:

• http://waytag.ru

Твиттеры:

• Твиттер проекта (@WaytagRu)!
• Дорожная ситуация в Чебоксарах (@Chebway + #chebway)
• Дорожная ситуация в Ульяновске (@Ulway + #ulway)

Почта для связи:

mail@waytag.ru

Я написал плагин для этого. https://github.com/Andrew8xx8/jekyll-link

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

Например, имеем такой шаблон с меню:

1
2
3
4
5
6
7
8
9
10
11

 <ul>
   <li>\{% link /blog Blog %\}
   <li>
     {% link /about About %}
     <ul>
       <li>{% link /about/author Author %}
     </ul>
   </li>
 </ul>

На странице с автором (/about/author) сгенерируется такой код:

1
2
3
4
5
6
7
8
9
10
11

 <ul>
   <li><a href="/blog">Blog</a></li>
   <li>
     <a href="/about" class="current">About</a>
     <ul>
       <li><a href="/about/author" class="current">Author</a>
     </ul>
   </li>
 </ul>

Смешно, но документация с примерами к плагину занимет больше строк чем сам код.

Первое, что нужно сделать, подключить эту папку в автозагрузку в config/application.rb:

1
2

config.autoload_paths += %W(#{config.root}/lib)
config.autoload_paths += Dir["#{config.root}/lib/**/"]

Затем тестирование.

Плохая идея подключать эти тесты прямо в test_helper.rb, типа такого:

1

Dir[Rails.root.join("test/lib/*.rb")].each {|f| require f}

Подключённые таким образом тесты будут выполнятся при любом раскладе, даже при запуске тестов определённого типа например rake test:functionals.

Правильным решением этой задачи является подключение дополнительных тестов через Rake Task.

Для этого нужно в создать или добавить в файл lib/tasks/test.rake новую задачу описывающую запуск дополнительных тестов:

1
2
3
4
5
6

namespace :test do
  Rails::SubTestTask.new(:lib => "test:prepare") do |t|
    t.libs << "test"
    t.pattern = 'test/lib/**/*_test.rb'
  end
end

Теперь тесты доступны для запуска через rake test:lib.

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

1
2
3

lib_task = Rake::Task["test:lib"]
test_task = Rake::Task[:test]
test_task.enhance { lib_task.invoke }

Чтобы научить tconsole понимать наши тесты нужно добавить либо в проект, либо в домашнюю директорию файл .tconsole, в котором добавить lib как тип тестов. Моя конфигурация для Rails приложения:

В связи с этим я решил привнести немного автоматизации в этот процесс.

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

1
2
3
4
5

  --tab Open a new tab in the last-opened window with the default profile
  --hide-menubar Turn off the menubar
  --maximize Maximise the window
  -e, --command Execute the argument to this option inside the terminal
  -t, --title=TITLE Set the terminal title

Исходя из этого команда для открытия терминала без строки меню с двумя вкладками и открытыми в них vim и zsh выглядит так:

1

  gnome-terminal --maximize --hide-menubar --tab --tab

Добавим названия заголовков:

1

  gnome-terminal --maximize --hide-menubar --tab -t "VIM | myproj" --tab -t "CONSOLE | myproj"

Добавим исполнение команд:

1

  gnome-terminal --maximize --hide-menubar --tab -e "zsh -c 'cd ~/myproj && vim'" -t "VIM | myproj" --tab -e "zsh -c 'cd ~/myproj; exec zsh" -t "CONSOLE | myproj"

Важный аспект состоит в том, что вкладка закрывается сразу же после выполнения команды, поэтому если нужно загрузить shell, следует исползовать exec.

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

P.S. * Более подробно о доступных опциях терминала можно узнать выполнив: gnome-terminal --help-all * Для Linux Mint все опции в силе. Просто используйте mate-terminal вместо gnome-terminal * Для bash всё тоже самое, только zsh следует изменить на bash, либо на другой ваш любимый Shell.

В стандартной поставке уже определены 5 видов динамических объектов, это Продукты, Страницы, Категории, Компании (только для редакции Multivendor), Новости.

Прикладное значение

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

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

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

В менеджере блоков на локации с dispatch=products.view, при редактировании любого блока, у него есть дополнительная вкладка Status, на которой можно задать для каких-либо продуктов статус отличный от установленного по умолчанию, т.е. включить блок где-то, если он выключен глобально и наоборот.

Принцип работы

Функционал динамических объектов реализуется в блок менеджере автоматически по средствам описания объекта в схеме dynamic_objects, по этому при желании можно дополнить эту схему в своём аддоне любым дополниительным объектом, как например расширяет общую схему аддон News & Emails.

Описание схемы на примере продуктов:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

<?php
array(
  // Название динамического объекта, будет использоваться в качестве object_type
  'products' => array (
    // Страница редактирования динамического объекта, на которой должна отобразиться вкладка Blocks в административной части сайта
    'admin_dispatch' => 'products.update',

    // Адрес страницы на которой в клинтской зоне и в панели управления блоками будет доступна работа с динамическим объектом
    'customer_dispatch' => 'products.view',

    // Ключ в $_REQUEST по которому будет определяться идентификатор объекта
    'key' => 'product_id',

    // Настройки пикера, который будет использоваться в административной части сайта
    'picker' => 'pickers/products_picker.tpl',
    'picker_params' => array (
      'type' => 'links',
    ),
  ),
)

Когда пользователь запрашивает, напрмер, страницу с dispatch=products.view, то магазин определяет, что эта страница принадлежит динамическому объекту products и ищет в пришедших в скрипт параметрах product_id. Если такой находится, то все данные для генерации страницы будут запрошены через API блоков с указанием соответствующего типа и идентификатора, если не был по диспатчу найден тип блока в схеме или ключевой параметр, то данные будут генерироваться без учёта динамического объекта, то есть выведется всё со значениями установленными глобально.

Файлы

• block_cache_properties.php — глобальные апдейт хендлеры для кеша блоков;
• dispatch_descriptions.php — список диспатчей и соответсвтующих лангвар. Нужно только для генерации списка для поля Dispatch при добавлении/редактировании локации;
• blocks.php – основная схема блоков;
• dynamic_objects.php — описание динамических объектов;
• fillings.php — дополнительные параметры для филингов;
• templates.php — дополнительные параметры лдя шаблонов.

Основая схема

1
2
3
4
5
6
7
8

  'тип блока' => array (
    'settings' => 'Список настроек (а)',
    'templates' => 'Список шаблонов (б)',
    'content' => 'Список контента (в)',
    'wrappers' =>' Список враперов (г)',
    'icon' => 'Путь до иконки',
    'cache' => 'Параметры кеша, если отсутствует, то блок не кешируется.'
  );

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

Список настроек предсьтавляет сабой набор пар типа ключ => значение, где ключём будет имя настройки. Оответсвтенно этому имени должна быть определена языковая переменная которая определяет название при выводе этой настройки.

Значемнием будет массив параметров определяющих эту настройку:

1
2
3
4
5
6
7
8
9
10
11
12

'имя_настройки' => array(
    'remove_indent'   => 'Если истинно, то при отображении в админке у настройки не будет отступа справа'
    'required'        => 'Если истинно, то в настройках блока поле будет обязательно для заполнения'
    'option_name'     => 'Имя языковой переменной для названия, если не задано в качестве него будет использоваться имя_настройки'
    'default_value'   => 'Значение по умолчанию'
    'values'          => 'Список вариантов настройки. Массив пар ключ => значение для настроек типа selectbox, multiple checkboxes'
    'no_lang'       => 'Если истинно, то при отображении в админке у списка вариантов занчение варианта будет выводится как есть, иначе интерпретирвоанться как языковая переменная'
    'values_settings' => 'Применяется только с настройкой типа selectbox. В этом параметре задаётся список вариантов и дополнительные настройки, которые будут появлятся только при выборе определённыз вариантов родительского списка. В качестве примера см. схему блока аддона Rss Feed.'
    'picker'        =>' Шаблон пикера. Применяется только с типом настройки picker.'
    'picker_params'   => 'Настройки пикера. Применяется только с типом настройки picker.'
    'template'        => 'Путь к шаблону. применятеся только с типом настройки "template"'
  );

Типы настроек:

• checkbox — гuалочка;
• input — поле ввода;
• input_long — поле ввода с классом input-text-long;
• multiple_checkboxes — список галочек;
• text — поле ввода текса типа WYSIWYG;
• simple_text — обычное поле ввода текста без WYSIWYG;
• picker — пикер;
• template — шаблон. Вместо сеттинги будет тоображаться тот шаблон, который указан в параметре template;
• enum — перечесление объектов. Используется только в секци content

б) Список шаблонов может быть:

1
2
3
4
5
6

  'путь_к_шаблону' => array (
    'settings' => 'Список настроек (см. ниже)',
    'fillings' => 'Массив из филлингов которые доступны для этого шаблона (все сотальные филлинги будут автоматически исключены из списка)',
    'params' => 'Массив параметров, которые будут переданы в функцию получения элементов блока',
    'bulk_modifier' => 'Групповой модификатор. Функция которая применится к элементам блока перед выводом'
  ),

Всё что есть в параметре ‘template’ в схеме блоков будет объединено с параметрами заданными в схеме templates.php, при генерации схемы, ключём является путь к шаблону.

Соответственно по ключу ‘template’ в схеме блоков может быть:

• А) Список путей к шаблонам с непосредственно полным переченем параметров, в таком случае не потребуется ничего писать в templates.php;
• Б) Список путей к шаблонам, а все параметры по соотвествующим ключам указаны в templates.php;
• В) Путь к папке с шаблонами, а все параметры по соотвествующим ключам указаны в templates.php;
• Г) Название функции которая возвращает список шаблонов, а все параметры по соотвествующим ключам указаны в templates.php или так же возвращаются функцией.

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

1
2
3
4
5
6
7

  'test_block' => array (
    'content' => array(
      'some_value' => array(
        'type' => 'text',
      )
    )
  )

В настроках блока в панели администрирования появится поле ввода в которое можно ввести значение. При отображении блока в кастомерке в шаблоне этого блока будет доступна переменная {$some_value} значение которой задано в админке.

В качестве элемента контента может быть любая настройка (см. пункт натсроек), специальный тип перечисление (enum), функция.

С настройками всё просто, то что пользователь сохранит в админке то и пойдёт в шаблон.

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

Параметры типа enum:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

  'имя_переменной' => array (
    'type' => 'enum',
    'object' => 'Название динамического объекта в схеме.'
    'items_function' => 'Функция генерации элементов'
    'fillings' => array ( // Филлинги, т.е. типы заполнения.
      'manually' => array ( // Ручной тип. Требует наличия параметров пикера.
        'picker' => 'pickers/companies_picker.tpl',
        'picker_params' => array (
          'multiple' => true,
        ),
      ),
      'some_another_filling' => array (
        'params' => array (

        ),
      ),
    ),
  ),

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

Если в качестве элемента контента используется функция, то значение этой переменной будет равно результату который вернёт эта функция. Формат определяни таков:

1
2
3
4

  'имя_переменной' => array (
    'type' => 'function',
    'function' => array('fn_get_languages'[, 'param1'][, 'param2'][..]),
    ),

г) В параметре wrapeprs как и в шаблонах может быть либо список враперов, либо путь к папке с ними. дополнительные настройки у них отсутствуют.

д) Если блок должен быть кешируемым то нужно определить ему свойство cache в схеме. В котором по ключу update_handlers перечислить список таблиц, при обновлении которых будет обновляться кэш.

В новом менеджере блоков все те статические блоки объединены в так называемый блок template у коготорого есть только одно свойство template в котором можно выбрать какой-либо шаблон для отображения из папки blocks/static_templates. Если вам нужно именно такой блок, то в аддоне достаточно создать папку blocks/static_templates и разместить там свой шаблон, который автоматичнски добавится к остальным. В принципе этот способ распространяется для всех основных блоков карты, расширить список их шаблонов можно по средствам добавления соотвествующей папки в аддоне.

Ключевым моментом здесь является использование CSS фреймворка 960gs (сайт проекта http://960.gs).

Данный фреймворк предназначен для быстрой, эффективной и кроссбраузерной вёрски веб-контента по модульной сетке размером 960 пикселей с разделением на 12 или 16 колонок.

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

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

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

Есть такой проект http://www.designinfluences.com/fluid960gs/ в нём реализовано как раз возможность растягивания лэйаута по ширине.

Для того что бы подключить у себя на сайте, нужно заменить скачать файл https://raw.github.com/bauhouse/fluid960gs/master/css/grid.css с репозитория проекта и заменить оригинальный файл карты your_skin_path/customer/css/960/960.css на скачанный.

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

Для того чтобы это исправить можно вручную добавить вложенным гридам нужную ширину, а родительскому гриду установить content-aligment full-width.

На примере стандартной шапки cs-cart это будет выглядеть так:

1
2
3
4
5
6
7
8
9
10
11
12

  html .helper-container .full-width {
    width: 100%;
  }
  html .helper-container .top-links-grid {
    width: 98.0%;
  }
  html .helper-container .search-block-grid {
    width:54.25%;
  }
  html .helper-container .cart-content-grid {
    width:41.75%;
  }

Тем же способом можно подключать файлы созданные с помощю сервиса Grids. Он позволяет создавать сетку различной фиксированной длинны.

1

[[MySnippet? &color=`[*MyColor*]`]]

Когда система будет обрабатывать шаблон она подставит значение параметра в вызов и оно передасться в сам снипет. Код MySnippet:

1

echo 'You have entered: '.$color;

Решение простое. Нужно в файле ~/.zshrc добавить эти строки:

1
2
3
4
5

bindkey "^[[1~" beginning-of-line
bindkey "^[[4~" end-of-line

bindkey "^[OH" beginning-of-line
bindkey "^[OF" end-of-line

Первые две для Putty другие для Gnome (Mate) Trerminal.

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

/*
 * Юзернейм
 *
 * Буквы, цифры, дефисы и подчёркивания, от 3 до 16 символов.
 * Начинаться должно всегда с буквы латинского алффавита
 */
    preg_match('%^[a-z][a-z0-9_-]{3,16}$%', $userName);

/*
 * Пароль
 *
 * То же что и юзер нейм только от 6 символов и может начинаться с цыфры
 */
    preg_match('%^[a-z0-9_-]{6,18}$%', $password);

/*
 * XML тег
 *
 * За открывающей скобкой < должно стоять слово из букв — имя элемента, затем могут быть атрибуты
 * — любые символы, кроме закрывающей скобки >. Далее — любой текст (содержимое) и закрывающий тэг,
 * т.е. <имя />, или как минимум один пробел, слэш и закрывающаю скобка (самозакрывающийся тэг).
 */
    preg_match('%<([a-z]+)([^>]+)*(?:>(.*)</\1>|\s+/>)$%', $xmlTag);

/*
 * Email
 *
 * Общий вид — логин@поддомен.домен. Логин, как и поддомен — слова из букв, цифр, подчёркиваний,
 * дефисов и точек. А домен (имеется в виду 1го уровня) — это от 2 до 6 букв и точек.
 */
    preg_match('%^([a-z0-9_\.-]+)@([a-z0-9_\.-]+)\.([a-z\.]{2,6})$%', $email);

/*
 * URL
 *
 * Первым делом — необязательный протокол (http:// или https://), затем последовательность букв,
 * цифр, дефисов, подчёркиваний и точек (домены уровня > 1), потом домен нулевого уровня (от 2 до
 * 6 букв и точек) и, наконец, файловая структура — набор слов из букв, цифр, дефисов, подчёркиваний
 * и точек со слэшем в конце. Всё это может завершаться опять-таки слэшем.
 */
    preg_match('%^(https?://)?([\da-z\.-]+)\.([a-z\.]{2,6})([/\w \.-]*)*/?$%', $url);
/*
 * IP адрес
 *
 * 4 группы цифр (от 1 до 3 цифр в каждой) разделены точками. Если группа состоит из 3 символов,
 * то первый из них — 1 или 2; если 1, то остальные от 0 до 9, а если 2 — то второй от 0 до 5;
 * если второй символ от 0 до 4, то третий — от 0 до 9, а если второй 5 — то третий от 0 до 5.
 * Если же группа состоит из 2 символов, то первый — от 1 до 9, второй — от 0 до 9. В случае
 * односимвольной группы этим символом может быть цифра от 1 до 9.
 */
    preg_match('%^(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)$%', $ip);

/*
 * Комментаррии CSS
 * Находим первое вхождение слеш звёздочка, далее берём любой символ или последовательность
 * слеш звёздочка, пока не встретится последовательность звёздочка слеш. Квантификатор не жадный, по этому
 * матчит ближайшие открывающие и закгрывающие вхождения оставляя внутри открывающие
 */
    preg_match_all("%/\*(.|[^/*])*?\*/\s+%i", $cssCode, $comments);

1

Catchable fatal error: Argument 1 passed to xPDOObject::load() must be an instance of xPDO, instance of modX given in core/xpdo/om/xpdoobject.class.php on line 404

Очень долго думал как решить. Оказалось суть в том, что при выходе из скриптанеправильно обрабатываются хендлеры повешенные на сессию. Что бы это исправить нужно добавить перед каждым выовом exit() в файлах /manager/min/index.php и /manager/min/lib/Minify.php вот такую строку:

1

@session_write_close();

Возможно есть ещё места где может понадобиться такой “хак”.