Это перевод достаточно важной статьи про GitLab Flow, альтернативе Git flow и GitHub flow. Статья была написана в 2014, так что скриншоты успели устареть. Тем не менее сама статья более чем актуальна:

---

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

• Не описан точным образом весь рабочий процесс,
• Вносится ненужная сложность,
• Нет связи с трекером задач (issue tracker).

Мы хотим представить вам GitLab flow — чётко определённый набор практик, решающий эти проблемы. Он объединяет в одну систему:

• Практику разработки, управляемой функциональностью (feature driven development),
• Использование feature-веток (feature branches),
• Трекер задач.

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

— Это теперь называется Front-End инженер, но да, я — именно он. Я работаю с вебом в 2016. Визуализации, музыкальные плееры, летающие дроны, которые играют в футбол, все что угодно. Я только что вернулся из JsConf и ReactConf, так что я знаю новейшие технологии для создания веб-приложений.

— Круто. Мне нужно создать страницу, которая отображает последние действия со стороны пользователей, так что мне просто нужно получить данные от REST и отобразить их в какой-то фильтруемой таблице, ну и обновлять её, если что-то изменится на сервере. Я думал, может быть, использовать JQuery для извлечения и отображения данных?

— О, Мой Бог! Нет! Никто больше не использует JQuery. Ты должен попробовать React: это — 2016!

CSS-препроцессоры в своё время значительно облегчали работу по написанию CSS кода. Однако в некотором роде все они были несовершенны и имели значительные изъяны в работе. А потому на смену препроцессорам пришёл постпрепроцессор PostCSS.

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

Человек изобрел компьютеры, чтобы они выполняли за нас большую часть повторяющихся задач. Это позволяет нам экономить много времени и использовать его с максимальной пользой. И, так как эта статья о front-end разработке, в этой области таких задач много: компиляция css- и js-препроцессоров, сборка спрайтов, оптимизация изображений, минификация файлов и др.

Недавно встала задача сверстать сайт не просто быстро, а очень быстро.

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

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

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

Порывшись в интернете, нашел плагин gulp-rigger. Получаса хватило для того, чтоб понять, что это совсем не то, что нужно:

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

Это пост можно сказать является дубликатом моей предыдущей подборки “Самые нужные плагины для Grunt”. Дело в том, что спустя много часов поиска я не нашел крутых плагинов для Gulp, которых нет для Grunt за исключением пары весьма специфичных утилит. Всё как раз наоборот, но проигнорировать множество пользователей Gulp я не мог. Все недостающие плагины я выделил, потому что Gulp умеет использовать их из Grunt, как и Grunt из Gulp.

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

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

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

Впервые за пять лет разработки интернет-сайтов я столкнулся с весьма неожиданной проблемой, стоившей мне многих часов поиска, нервов и волос на голове. Внезапно я обнаружил, что на новом сайте, который у меня сейчас в разработке на локалхосте, дублируются INSERT запросы к БД. Отправляю один комментарий через форму, а в базу вставляются два. Если вы не знаете, как связана эта проблема с Chrome, favicon.ico и ModRewrite, то добро пожаловать под кат.

В силу того, что большинство разрабатываемых мною сайтов создается с использованием CMS Wordpress и приходится постоянно сталкиваться с нетривиальными задачами, решил делиться с вами опытом использования различных плагинов. Как бесплатных так и платных, причем попробую придерживаться такого формата: одна статья — один плагин. Постараюсь рассматривать только действительно заслуживающие внимания разработки, и вот в первом своем рассказе поведаю вам об OptionTree — прекрасное, на мой взгляд, решение для создания страницы с пользовательскими настройками сайта.

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

Что такое шорткоды

Начиная с версии 2.5, разработчики WordPress ввели понятие «Shortcodes API». Этот функционал позволяет создавать и использовать макрокоды в страницах сайта или в записях блога. Например, простая и короткая запись добавит на странице целую фотогалерею.

Более подробно прочитать о шорткодах и узнать, как создавать простые шорткоды, вы можете из документации WordPress.

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

1. Подключение сторонних скриптов и запуск только при наличии шорткода на странице.
2. Многоуровневый шорткод.
   
   • Составной шорткод.
   • Вложенность шорткодов.
   
   

WordPress, будучи одной из самых популярных CMS в мире, снабжен подробной документацией, а точнее, даже двумя. В связи с чем ни в коем случае не стоит воспринимать этот текст как описание неких “best practices” и уж точно никто не заставляет слепо следовать описанному. Статья — просто быстрый ответ на вопрос «как?!» (следующий абзац) и подробное описание всего, что нужно знать чтобы заставить WordPress отвечать на AJAX-запросы (вся остальная статья).

Кратко

Традиционно для AJAX-запросов нужно две вещи: скрипт на сервере (бекенд), который будет отвечать на запросы, и скрипт на клиенте (фронтенд), который будет эти запросы делать. WordPress позволяет делегировать функции на обращение к специальному URL, по которому находится обработчик запросов.

Итак, работает это, «WordPress-way», вот так:

1. На бекенде с помощью функции admin_url получаем ссылку на обработчик AJAX-запросов и передаем ее во фронтенд одним из способов. Именно к этой ссылке мы будем делать наши запросы.
2. На бекенде регистрируется хук с функцией для обработки некоего экшена. Назовем этот экшен, например, get_posts.
3. Фронт-енд делает запросы к URL-у из пункта 1, передавая имя экшена. Например, ?action=get_posts.
   На бек-енде, если на экшен зарегистрирован хук, выполняется заданная нами функция.

Вот так вот просто. Теперь подробнее.