Приветствую тебя, Хабрачеловек.

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

Итак.

Я думаю многие любопытные люди уже знают, как нужно верно работать с SVN.
Но во многих статьях это описано достаточно поверхностно. Хочется немного приоткрыть завесу верного цикла версионирования, при разработке проекта, на примере TortoiseSVN.
И так, поехали

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

Два года назад покинув Петерхост мы (schors и adnull) не переставали думать о хостинге, работая над проектами с ним не связанными. Мы активно работаем с Python, и вопрос «что делать?» для нас имел один ответ — качественный хостинг для Python приложений.

Хостинг для фанатов Python — DiPHOST

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

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

Если вы еще сомневаетесь — можете взять и попробовать — 7 дней вы можете тестировать наш хостинг в рабочем режиме совершенно бесплатно.

Для фанатов svn/git/bzr/mercurial — вы можете легко развертывать приложение со своего любимого svnserve/github/launchpad/bitbucket — мы поддерживаем все эти VCS.

Но это только начало. Для фанатов rails мы тоже готовим что-то интересное.

Ура, товарищи!!

Это – нулевой выпуск колонки Cisco-любителей и Cisco-профессионалов!



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

Шрифты в Em/% хороши всем — возможностью пользователей IE увеличивать кегль, заботой о пользователях, что предпочитают увеличивать размер шрифта браузера по-умолчанию, чтоб лучше видеть текст, да и просто являются нормой для профессиональных верстальщиков.

Минусы: … их вроде как нет, но!
А что если у пользователя разрешение экрана выставлено не в стандартное 96 dpi, а в 120?
Сайт с увеличенными шрифтами смотрится уже не так красиво, как нарисовал дизайнер — ведь масштабируются только шрифты, а не весь сайт! А разрешение 120dpi становится всё популярней, особенно на ноутбуках! Что же делать? Возвращаться к px?

Нет!

Знаете, есть на свете такой отличный миниатюрный proxy-сервер под названием «3proxy», который для своих мелких габаритов умеет достаточно много. Я его использую в домашних условиях (хотя он этим не ограничивается).

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

Представляю Вам третью статью из серии jQuery для начинающих. В этот раз я постараюсь рассказать о реализации AJAX запросов...

Немного предыстории. Не так давно я решил присоединиться к проекту w3af (Web Application Attack and Audit Framework). В этом приложении есть возможность автоматизировать повторяющиеся действия с помощью скриптов команд (такой аналог батников и шелл-скриптов).

# This is a test for the 404 fingerprinting of the core
plugins
output console,textFile
output
output config textFile
set fileName output-w3af.txt
set verbose True
back
output config console
set verbose False
back
discovery pykto,serverHeader

discovery config pykto
#set mutateTests True
back

back
target
set target localhost/w3af
back
start

Постоянно работая с ними, я подумал, а почему так все блекло? И родилась идея сделать простую подсветку синтаксиса для w3af скриптов.

Помню, как-то проскакивала пара записей (здесь и здесь) по поводу импортирования данных из Google Analytics для отображения сводных диаграмм на сайте, в общем, как на хабре. Прочитав вышеупомянутые топики и не обратив особого внимания тогда, я о них успешно «забыл» и пошел себе дальше. И вот сейчас, появилась необходимость реализовать нечто подобное на одном из своих проектов.



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

UPDATE:
Добавил еще одну версию, подробности и линк под катом.

Не реально? Реально, если собрать самому и правильно подобрать комплектующие.
А теперь слайды:

Многие из нас собирали компьютер сами, из комплектующих. Дело не сложное, соединить с десяток шлейфов, да завинтить столько же винтиков. Но мало кто сталкивался с самостоятельной сборкой серверов, причем не обычных а в промышленном формате под стойку 19 дюймов. В этом небольшом обзоре я опишу свой опыт сборки такого сервера, постараюсь показать что это не сложно, и остановлюсь на главных моментах, на что нужно смотреть. На написание этого обзора меня толкнуло то, что информации о сборке rack 19’ серверов в рунете очень мало, и приходилось её искать буквально по крупицам.

Доброго времени, хаброчеловеки!

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

Этот топик мой ответ на жалобу одного человека, что «баги достали».

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

Первые задачи могут быть такие:

• Обеспечить интеграционное тестирование, чтобы каждое обновление на production не было головной болью.
• Обеспечить регрессионное тестирование – чтобы выявленные ошибки не возникали опять (отслеживались автоматически).

По долгу службы мне приходится работать с Cake и Sphinx. Однажды мне надоело делать поиск к сфинксу ручками, и я решил написать небольшой behavior.

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

Здесь представлены

Обсуждая с различными людьми — в большинстве своём опытными разработчиками — классический труд «Приёмы объектно-ориентированного проектирования. Паттерны проектирования» Гаммы, Хелма и др., я с изумлением встретил полное непонимание одного из базовых подходов ООП — различия классов и интерфейсов.

<?php

/**
* Пример реализации Generic-класса
*
* Возможности:
* 1. Осуществляет доступ к параметрам класса через методы get* set* (accessors/mutators)
*     Пример: $object->setName('Dima'); $object->getName();
*     При изменении стандартного поведения метода (добавление дополнительной логики)
*     можно просто определить его в классе при этом не изменяя интерфейс класса.
* 2. Поддерживает встроенную валидацию данных с возможностью использовать или заранее
*     определенные типы данных (numeric, string, email, date и др.)
*     или регулярные выражения.
* 3. Имплементирует паттерн Lazy initialization для инициализации объектов.
*     Позволяет загружать параметры объекта из БД (например) не сразу при инициализации,
*     а только при первом запросе.
*
* Видимые недостатки:
* 1. Отсутствует возможность использовать автокомплит в IDE, так как методы явно не определены
*
* Плюсы:
* 1. Позволяет избежать дублирования кода при определении однотипных методов set и get
* 2. Сокращает код классов и централизует управление параметрами
* 3. При необходимости можно расширить функциональность. Например, добавив callback функции
*     или принудительную фильтрацию данных.
* 4. Избавляет от рутинных обязанностей проверки входящих данных, тем самым
*     обеспечивая некоторый уровень безопасности.
*     Это совсем не дает 100% гарантии — не стоит забывать об этом.
* 5. Не вносит коррективы в интерфейс классов. Можно легко сочетать обычные классы и классы
*     наследующие GenericObject без видимых различий для клиентов класса. При необходимости
*     можно легко отказаться от использования просто переопределив все гетеры и сетеры.
* 6. Упрощает работу с классами, предоставляя удобный и естественный способ
*     инициализации объектов:
*     $obj1 = new Class(123);
*     $obj2 = new Class(array(
*         'param1' => 'value1',
*         'param2' => 'value2')
*     ));
*/

Модуль для nginx, с помощью которого достаточно просто мониторить прогресс загрузки файлов на сервер. Ранее были подобные решения, через модули к php, ruby, через стороние скрипты, flash объекты итп. Автор предлагает универсальное решение на уровне web сервера. Подробную информацию и инструкции вы можете найти на wiki.codemongers.com (кстати, один из лучших проектов, посвященных nginx`у). Тут я хотел обратить внимание на другое.
Использовал модуль совместно с nginx upload module, работает на ура. Однако файлы, что я заливаю, достаточно большие (поддерживаю файлообменник), пытался запихнуть в директиву upload_progress размер обрабатываемых файлов — 1g, при релоаде nginx`а получил варнинг, мол непонятный размер вы поставили. Странно, т.к. в client_max_body_size у меня стоит 1g и нормально себя чувствует. Глянул исходники nginx`а и модуля, выяснелось, что модуль обрабатывает директиву upload_progress функцией ngx_parse_size, тогда как сам nginx обрабатывает ту же client_max_body_size соседней функцией ngx_parse_offset, функции абсолютно идентичны (на мой взгляд), разве что первая не понимает размерность «g», а вторая понимает =) Для того, чтобы модуль нормально обрабатывал размерность в директиве upload_progress, надо в исходнике модуля (ngx_http_uploadprogress_module.c) в строчке 1151 исправить ngx_parse_size на ngx_parse_offset.
В общем это не критично, т.к. директива нормально обрабатывает значение 1024m, но как-то нелепо выглядит подобная запись =)))
А вообще модуль очень понравился, очень удобное решение, не зависящее от бэк-енда.

update: Внимание, совершил глупую ошибку. Стыдно. Деректива upload_progress задает не максимальный размер загружаемых файлов для указанной зоны, как я думал, а размер оперативной памяти, выделяемой для обсчета одной загрузки в эту зону. Значение для этой дерективы — 1,2m, максимум 10-20m. Задавая 1g вы будете тратить гигабайт оперативки на каждую загрузку. Стыдно, ошибку не повторяйте.
p.s. тем не менее баг найден, автору сообщил, он обещал исправить.

Недавно, в Dojo появилась возможность производить cross site POST запросы, т.е. отправка POST запросов на другие сайты, с другими доменными именами. Это событие осталось незамеченным в нашем сообществе JavaScript разработчиков. По крайней мере, никто и слова про это не сказал. А зря…

В один прекрасный момент