Хабрахабр: Web-разработка / Блог / Захабренные Голосов: 1 Адрес блога: http://habrahabr.ru/blog/webdev/ Добавлен: 2008-06-12 19:52:21 блограйдером ZaiSL

[Перевод] #NoHacked: устранение последствий взлома с загрузкой URL, содержащих бессмысленный текст

2015-09-08 13:58:27 (читать в оригинале)


Привет, Хабрахабр! Сегодня в рамках кампании #nohacked мы хотели бы поговорить о том, как решить проблему с несанкционированным внедрением контента на сайт. Даже если вы не подвергались такой атаке, не пренебрегайте нашими рекомендациями – они помогут защитить ваш ресурс и от других методов взлома. Следите за обсуждением в Twitter и Google+ с помощью хештега #nohacked (см. часть 1, часть 2, часть 3, часть 4).


Читать дальше →

---

Совместное редактирование. Часть 2

2015-09-08 12:52:15 (читать в оригинале)




Добрый день! Недавно мы начали цикл статей о совместном редактировании. В первой статье я рассказал о задаче неблокирующего редактирования и возможных подходах к его реализации. Напомню, что в итоге в качестве алгоритма мы выбрали Operation Transformation (OT). Также был анонсирован рассказ о его клиент-серверном варианте, и сегодня я освещу подробности его работы. Кроме того, вы узнаете, почему отмена в OT работает иначе и чем грозит столкновение с суровой реальностью.

Дальше вас ждет много алгоритмов и диаграмм. Думаю, вам будет интересно.
Читать дальше →

---

[Из песочницы] 100 из 100 в Google PageSpeed Insights (Баг или фича)?

2015-09-07 15:16:38 (читать в оригинале)


Многие из Вас наверное пользовались замечательным сервисом от Google: PageSpeed Insights? Хотите получить заветные 100 из 100?


Картинка для привлечения внимания

А дело-то за маленьким.
Читать дальше →

---

[Из песочницы] Firebase-queue: стероиды для firebase

2015-09-07 15:11:29 (читать в оригинале)


Про Firebase уже не раз писали на хабре. Ключевым преимуществом этой системы является то, что в некоторых случаях на ней можно построить завершенное веб-приложение работающее с данными в реальном времени. Располагая возможностью редактирования правил доступа к базе данных и тем что эти правила можно устроить на основе пользователей (которых сюда тоже завезли), в принципе можно обойтись и без какого-либо backend'a. Но обычно возникают такие проблемы, которые лучше решить «со стороны» чем плодить велосипеды в правилах (например).

В середине мая разработчики объявили о выходе firebase-queue. Это javascript-библиотека с помощью которой можно организовать работу с данными в базе, как с задачами. Работает это следующим образом: определяем ячейку задач, используя Queue() на сервере устанавливаем связь. Теперь, когда в этой ячейке появится новый элемент, сервер сделает необходимые действия, если нужно оповестит о прогрессе и ошибках, и по завершению удалит задачу. В итоге мы получаем возможность покрыть много проблем возникающих в разработке с Firebase — согласовать данные, провести их дополнительную валидацию (например проверить на спам и мат) отправить их в другое место (например загрузить картинку на хостинг) и другое.
Читать дальше →

---

[Из песочницы] Ansible и Rails — гибкая замена Capistrano с сохранением знакомого комфорта

2015-09-07 15:09:38 (читать в оригинале)


Capistrano — любимый многими rails-разработчиками инструмент, с помощью которого можно быстро и без заморочек автоматизировать развертывание вашего приложения. Capistrano — стандарт де-факто для системы развертывания RoR, must-know технология для любого уважающего себя рубиста, тот инструмент, которому в своё время завидовали разработчики на python и PHP.
Несмотря на комфорт, от которого не хочется отказываться, чем более сложные задачи мне приходилось решать, тем чаще Capistrano показывал себя к ним не приспособленным.

Я отметил следующие недостатки:

• Известные проблемы со скоростью. Вследствие своей универсальности, Capistrano деплоит медленно, выполняя лишние проверки и вызовы, которые вы не всегда можете контролировать.
• Последовательный деплой. Небыстрое время развертывания нужно умножить на количество целевых серверов.
• Сильная связанность с рельсами. Конфиги и зависимости Capistrano переплетаются с приложением, становясь его частью. Нельзя создать новое окружение-развертывания (например сервера для раннего выкатывания функционала) без создания нового rails-окружения. В сложных ситуациях Capistrano заставляет уходить от хорошей практики держать только development, test и production окружения.
• Плагины — палка о двух концах. Давая возможность быстро “прикрутить” развертывание той или иной зависимости приложения, плагины лишают вас контроля ситуации, заставляют действовать так, как действует разработчик плагина. О влиянии лишних “телодвижений” плагинов на скорость деплоя я написал выше.
• Сложный деплой гетерогенных приложений. Трендом последних лет в рельсах стало выделение самых тяжелых (бекграундных или сетевых) задач в отдельные сервисы, не обязательно написанные на ruby. В такой ситуации capistrano заставляет вас плодить зоопарк из разных систем развертывания для разных языков и технологий.

Многие ruby-разработчики перешли на Mina или решают свои проблемы с помощью ещё более сложных систем управления конфигурациями вроде Chef и Puppet. Все они имеют свои особенности и недостатки и в разной степени решают описанные выше проблемы. Мне же удалось их решить их с помощью Ansible, не растеряв преимуществ Capistrano, к которым я привык.

Ansible это инструмент для управления конфигурациями и в его задачи входит не только описанное в этой статье выполнение удаленных команд на серверах для развертывания и управления отдельным приложением, но и автоматизация серверного администрирования посредством хранимых серверных конфигураций (ролей на языке Ansible). А значит Ansible (как впрочем и Chef и Puppet) позволяет гораздо больше, чем Capistrano и в конечном счете они все не идут с ним ни в какое сравнение. Однако, задача этой статьи дать rails-разработчикам отправную точку для миграции и разъяснить на этом примере основы Ansible. В конце этой статьи, волшебная команда cap production deploy превратится в ansible-playbook deploy.yml -i inventory/production
Кому интересно как — прошу под кат.
Читать дальше →