О чем это я?

С чего начинается практически каждое web-приложение на Erlang? Не знаю, у кого как, а у меня, как правило, со строчек кода, ответственных за запуск Ковбоя и обслуживание запросов. С функции обновления правил роутинга. Причем всегда это одно и то же — только роуты отличаются, порт и количество акцепторов, может быть. И это можно сделать проще. Догадались уже, к чему я клоню? Нет, это не очередной фреймворк. Это превращение встраиваемого ковбоя в отдельно запускаемое приложение. То есть мы пишем наше приложение, хендлеры Ковбоя, но сам Ковбой не трогаем. Вообще. Ни зависимостей не указываем, ни при старте приложения не запускаем. Любопытно? Добро пожаловать под кат.

Привет!
В этом туториале я планирую показать тем, кто еще не знаком с веб-сервером Cowboy, как им пользоваться. Для людей, которые имеют опыт работы с ним, данный туториал врядли будет интересен, а вот для тех, кто знает о Ковбое лишь по наслышке — welcome!

Что мы будем делать:

1. Простейшая установка и запуск сервера
2. Краткий обзор роутинга, обслуживание статики
3. Шаблонизация с помощью ErlyDTL (Django Template Language для Erlang)

Интересно, скольким из вас приходилось хотя бы иногда, но повторять рутиные действия для настройки автодеплоя с гитхаба на сервер: создать ssh-ключ, добавить его для репозтория проекта на Гитхабе, создать скрипт, который будет слушать какой-то адрес, добавить вебхук в интерфейсе гитхаба, который будет дергать этот скрипт… Уфф… А что, если я скажу вам, что автоматизировал все эти действия по-максимуму? Да, теперь вам нужно выполнить всего пару команд и автодеплой запущен и работает! И все это благодаря Гитхабайзеру.

Вольный перевод новости:
wiki.php.net был скомпрометирован и атакующим удалось собрать данные от аккаунтов. Другие подразделы инфраструктуры php.net, по нашим данным, не пострадали. Наша главная забота сейчас — целостность исходников. Мы провели всевозможные проверки на каждый коммит начиная с выпуска php версии 5.3.5, чтобы удостовериться, что украденные аккаунты не были использованы для внедрения вредоносных кодов — все в порядке. Скомпрометированные машины были очищены, все пароли к аккаунтам в SVN сменены.
Мы продолжаем расследование по факту атаки, которая являлась сочетанием использования уязвимости в движке софта Wiki-раздела и эксплойта к Линуксу для получения прав администратора.
источник

UPD: 20.03, 10:20 — wiki.php.net и windows.php.net до сих пор не доступны (да-да, страничка для пользователей Windows вчера также была недоступна, но я это заметил еще до прочтения новости, а после не додумался связать). Это лишь мои наблюдения — может, кто-то еще что-нибудь заметил?

Фреймворк — это хорошо, это здорово, это возможность сэкономить кучу времени на раздумьях над архитектурой будущего приложения, но… Фреймворк как таковой — это каркас. И, на примере Kohana 3.0, о которой в данной статье пойдет речь, каркас этот надо, в той или иной степени, допиливать.
Теперь давайте по-порядку, чем мы сейчас займемся:

• -Расширим базовый контроллер, добавив в него жизненно необходимые методы и работу с юзерами (которая присутствует в 99% проектов, хотя бы на уровне административного логина)
• -Создадим свой фронт-контроллер для более удобной и красивой работы с вью-файлами
• -Реализуем вывод ошибок валидации через фронт-контроллер
• -Улучшим базовый класс View
• -Ну и еще кое-какие полезные мелочи

Итак, начнем…

Приветствую!
Данная статья будет скорее полезна для новичков, но, с учетом отсутствия обширной документации по фреймворку, таких немало и поэтому я решил все-таки опубликовать ее.
На написание этой статьи меня также сподвигло множество вопросов, связанных с работой с медиа-файлами в Kohana и некоторые куски кода во многих просматренных мной исходниках проектов на Ko3 (люблю рассматривать реализации различных проектов на этом фреймворке — за отсутствием документации порой сильно помогает).
И так, что же мы будем делать?
Мы напишем контроллер, который будет обрабатывать запросы вида media/css/default и возвращать нам (кэшированный, если есть) файл views/.../media/css/default.css, например.

Доброго времени суток!

Не так давно я начал свое знакомство с фреймворками впринципе и сразу столкнулся с таким вопросом — как же организовать простую смену шаблонов, чтобы в любой момент можно было добавить, скажем, в папку templates еще одну папку с шаблоном и безболезненно изменять шаблоны в будущем. Но в Kohana 3 (к сожалению, ничего не могу сказать о других фреймворках, так как работал с ними лишь поверхностно) во-первых все View-файлы лежат в папке views (все-таки templates проще и понятнее простому пользователю), а во-вторых, нет механизма выбора нужного View-файла из папки Views (кроме как подключение его напрямую). Что ж — сейчас я хочу рассказать, как это реализовать. Используемая версия фреймворка — 3.0.7, последняя на данный момент.
Давайте начнем.