Введение

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

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

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

Защита (или отсутствие защиты) от различных типов атак демонстрируется на примере протоколов популярных сегодня систем: Assist, Cyberplat, WebMoney, ChronoPay, Robokassa и PayPal (платёжные системы), а также OpenID, OpenAuth, OAuth (децентрализованная аутентификация).

Условия

Мы используем MySQL для хранения любых данных FriendFeed. Наша база данных растёт вместе с числом пользователей. Сейчас у нас более 250 миллионов записей, это записи пользователей (post'ы), комментарии, оценки («likes»)

По мере того как росла база данных, мы время от времени имели дело с проблемами масштабируемости. Мы решали проблемы стандартными путями: slave-сервера, используемые только для чтения, memcache для увеличения пропускной способности чтения и секционирование для увеличения пропускной способности записи. Однако, по мере роста, использованные методы масштабируемости привели к затруднению добавлению новой функциональности.

В частности, изменение схемы базы данных или добавление индексов к существующим 10-20 миллионов записей приводили к полной блокировке сервера на несколько часов. Удаление старых индексов требовало времени, а не удаление ударяло по производительности, так как база данных продолжала использовать их на каждом INSERT. Существуют сложные процедуры с помощью которых можно обойти эти проблемы (например создание нового индекса на slave-сервере, и последующий обмен местами master'a и slave), однако эти процедуры настолько тяжелые и опасные, что они окончательно лишили нас желания добавлять что-то новое, требующее изменение схемы или индекса. А так как наши базы сильно распределены, реляционные вещи MySQL как например JOIN никогда не работали для нас. Тогда мы решили поискать решение проблем, лежащее вне реляционных баз данных.

Существует множество проектов, призванных решить проблему хранения данных с гибкой схемой и построением индексов на лету (например CouchDB). Однако, по-видимому ни один из них не используется крупными сайтами. В тестах о которых мы читали и прогоняли сами, ни один из проектов не показал себя стабильным, достаточно зрелым для наших целей (см. this somewhat outdated article on CouchDB, например). А все это время MySQL работал. Он не портил данные. Репликация работала. Мы уже в достаточной мере понимали все его узкие места. Нам нравился MySQL именно как хранилище, вне реляционных шаблонов.

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

Что такое Fireworks и зачем он нужен

В нашей стране данный графический редактор не снискал популярности. Так уж сложилось, что стоимость пакета Adobe Creative Suite у нас в среднем равна стоимости интернет-трафика на его скачивание, либо стоимости носителя, на который его записывают. Отчасти поэтому все используют Adobe Photoshop и Adobe Illustrator для создания веб-дизайна. Ну вот сейчас, лично для меня, пришло время задуматься о лицензионности софта.

Я сам не являюсь веб-дизайнером, я программист. Основные задачи, которые я решаю с помощью графического редактора — это минимальная модификация растровой и векторной графики, нарезка готового дизайна, оптимизация изображений, создание прототипов и т.п. Photoshop и Illustrator без проблем решают эти задачи, однако их в состоянии решить и Fireworks. А теперь вспомним про стоимость Photoshop + Illustrator (700$ + 600$) и сравним со стоимостью Fireworks (300$).

Частенько бывает, что Fireworks не справляется с отображение родных файлов Photoshop и Illustrator. Возникают глюки с отображением некоторых эффектов. В таких случаях обычно помогает эталонный скриншот, который позволяет понять где проблема и при возможности исправить ее. Также есть альтернативные редакторы (Gimp, Pixelmator), которые открывают исходный файл, но уже со своими глюками, которых нет в Fireworks.

Таким образом, вряд ли Fireworks заинтересует дизайнеров, уже работающих в Photoshop, его основные пользователи — это программисты, верстальщики, проектировщики и небольшая часть дизайнеров (во всяком случае в России).

Подборка роликов о Fireworks

Покопавшись в рунете на предмет наличия видео о Fireworks на русском языке я наткнулся на некий вакуум. Все имеющиеся ссылки вели на Youtube. Вот к нему я обратился, а результаты поиска под хабракатом. Кому будут интересны эти ролики? Прежде всего программистам, отчасти верстальщикам, которые хотят понять как создается веб-дизайн и почему им не всегда нужен Photoshop.

В этой статье я поделюсь собственным опытом построения веб-сервера, работающего на CentOS 5.3.

Что требовалось:

• Полностью избавиться от Apache. Сервер должен был выдерживать хорошую нагрузку, распределяя статику и динамику.
• Нужна была поддержка последней версии libxml, малейшее различие в версиях делало сайт абсолютно нерабочим.
• Нужен был gzip
• И еще некоторые особенности, о которых я расскажу в самой статье

Все началось с этой темы на форуме, когда многие на полном серьезе стали рассуждать, мол, nginx совсем не быстрее Apache, и даже перевод документации с официального сайта был неубедителен. Как известно, нет ничего более приятного, чем провести тестирование и показать график для привлечения внимания. Вот например график по обще нагрузке на сервер, попробуйте угадать где тут этап тестирования Nginx, а где — Apache.

Ну а перед тем как узнать правильный ответ — немного про сервер и механизм тестирования.
Дабы исключить всякие подозрения на «подкручивание» своих VDS, тест проводился на стороннем сервере, любезно предоставленным мне для теста одним из участников форума вот в такой кнофигурации:
AMD Athlon X2 5600+ 4 GB DDR2 2×400 GB HDD с Linux Debian в минимальной установке. Весь софт устанавливался стандартным образом — через apt-get. И PHP и Apache ставились в минимальном режиме.
Для объекта тестирования я поставил очень легкий блог Moscquito, который работает без MySQL, написав туда пару постов и камменты.

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

Представляю вниманию общественности перевод достаточно большой статьи об использовании MySQL на ZFS, а так же сравнительное тестирование ZFS и UFS.

Всем привет. Сразу хочу сказать что статья расcчитана для тех, кто уже хорошо знаком с данным фреймворком. В новых версиях Zend Framework придумана концепция инициализации компонентов приложения через плагины ресурсов. В стандартной поставке имеется достаточное их количество, но одного я так и не нашел. Таковым является кэш. Побродив по просторам Интернета и не найдя аналогов, я решил написать свой. И так, приступим.

MyCalendar — это расширенная версия стандартного ExtJS-календаря. Календарик не привязан к конкретному бэкэнду т.к. работает только с JSON данными, а их хоть из ассемблера кидай =). На сайте автора уже представлено два бэкэнда на Grails и PHP в качестве демо для лучшего понимания внутреннего устройства.

Протестировано в IE, FF, Chrome.
Товарисчь anotherpit подсказывает, что в Opera все тоже работает (на первый взгляд).

Для ускорения Zend Framework очень действенен такой финт: собираем все классы, которые нам нужны, в один фаил, а потом включаем eAccelerator и инклудим его в самом начале. Один фаил + еАкселератор круче, чем много фаилов.

Под катом — рассказ, как я это сделал. Это не самое умное, лучшее и красивое решение, поэтому я рад послушать ваши советы и замечания. В общем, топик этот — ради ваших советов и замечаний — тех, что по делу, а не по поводу всякой херни типа орфографических ошибок. Спасибо!

Многие как и я используют Modules ресурс, который позволяет использовать отдельные Bootstrap файлы для каждого модуля. Но этого ресурса есть один недостаток — он всегда загружает все Bootstrap файлы в независимости от того какое модули мы используем в конкретном запросе. Я решил предоставить решение данной проблемы

Самое сложное в любой работе — это начать её. Итак, с чего же начать наше огромное клиентское приложение? В этой части я расскажу с чего начать и затрону три темы: Как организовать код, Что такое фасад, как его построить, что такое компоненты (и, конечно, как их начать писать).

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

Пока nerezus сочиняет статью о встраивании PHP, я постараюсь продолжить его рассказ о написании расширений. Рассказано будет далеко не всё, поскольку я считаю, что сложность наращивать надо постепенно, иначе материал будет трудноусвояемым и совсем не питательным. В связи с этим я всё-таки не расскажу в этот раз, как подменить операторы в классе, кто захочет, может почитать исходники модуля Operator от Сары Големон — основного автора какой бы то ни было информации о разработке расширений PHP.
Поскольку разработку я веду исключительно в линуксе, то писать мы будем без всяких хитрых аддонов к Visual Studio, ручками, с нуля :) А что, лучше сразу разобраться, а потом уже упрощать свой труд.

Как многим уже известно Zend_CodeGenerator появился в бете 1.8 Zend_Framework
Я хотел было потерпеть до релиза версии 1.8, но не удержался и решил всё таки попробавть «на зубок».
Мы будем генерировать класс формы на основе mysql таблицы.
Это действительно очень удобно и избавляет нас от порой рутинной работы.

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

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

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

В прошлом топике, я постарался разогреть ваш аппетит, показав на что способен python for s60. Сейчас же я вам покажу, насколько легко писать приложения. Мы пройдем весь путь, начиная от выбора и установки необходимого софта, до упаковки программы в sis пакет.

Оговорюсь сразу: в этой статье мы будем разбирать пример, работающий на symbian 9.4 (смартфоны с тачскрином), хотя вы без особого труда сможете переделать пример и под более ранние версии symbian. Кроме этого, рассказ будет вестись с учетом работы на windows. Пользователи других операционных систем, без проблем смогут подобрать необходимый софт под свою OS.

Кстати, у программы, которые мы разработаем в этом топике, есть аккаунт в twitter :)

Теория

Monit — самостоятельный демон, работающий от пользователя root. Демон работает на Linux, Free/Net/OpenBSD, SUN Solaris и некоторых других UNIX-системах. Это OpenSource проект, у которого есть «старший брат» — коммерческий проект MMonit. Последний обладает более широким функционалом в вопросе массового мониторинга, межсетевого взаимодействия и составления отчетов. Идея авторов проста — для одиночного сервера используем Monit, для большой сетевой фермы — MMonit.

Оригинал статьи на английском. Перевод: Boten, Deniska, MaxElc

Несколько дней назад я (здесь и далее — автор оригинальной статьи — Прим. пер.) написал о книгах, которые могут скачать начинающие пользователи, и прочитать их, чтобы изучить Linux самостоятельно. Сегодня в секции о Linux у нас есть кое-что и для опытных пользователей. Перед вами несколько советов, которые вы должны попробовать, если вы опытный пользователь Ubuntu Linux

Серия статей «Основы Python»

I, Начало
II, Строки
III, Списки, кортежи, файлы
IV, Генераторы списков
V, Определение функций, основы
VI, Расширенное определение функций

Об основах языка Python в сжатой форме

Продвинутый уровень

Сила и красота декораторов Короткий экскурс в метапрограммирование.
Итерируем все и вся Специфика циклов в Питоне.
Как я учился работать с XML
Консервация объектов в Python Использование модуля Pickle.
Memoization в Python Оптимизация работы программ.
Простейшее рисование с помощью PIL
Regexp и Python: извлечение токенов из текста
Как писать маленькие приложения на python с графическим интерфейсом (библиотека Qt).

http://netsago.org/ru/docs/1/12/
Одеваем скрипты Python с помощью EasyGui (добавляем простой диалоговый интерфейс)

http://djbook.ru/
Учебник по Django (Python-фреймворк для веб-приложений)