В предыдущей части мы начали бороться за память на 256 мегабайтном слайсе «на скорую руку». Результат был, но не столь эффектный как тот которого я добился на этот раз.

Я всегда догадывался, что причина всех моих неприятностей — apache. И чем больше я пытался его настраивать, тем больше в этом убеждался. Вывод? Попробовать заменить. Одно но — переход должен быть как можно более плавным, поскольку речь, ясно дело, о продакшене.

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

9 марта 2009 года объявлен очередным днём тестирования Ubuntu.

В России 9е марта это выходной. Так что сразу как опохмелитесь после Великого Женского Праздника (тм), не сочтите за труд загрузить себе свежий альфа-CD с вашим любимым u/k/xbuntu и тщательно изучить его.

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

После этого поставьте на работающую систему пакет virtualbox-ose, после чего установите в него свежую Ubuntu и проверьте, все ли возможности программ, которыми вы пользуетесь, на месте? Все ли заявленные функции работают?

Проверерьте, исправлены ли все ошибки, на которые вы натыкались в процессе эксплуатации предыдущих версий дистрибутива.

Внимательно запишите все выявленные недочёты создайте баг-репорт в Launchpad, или хотя бы запишите на форуме в разделе "Тестирование Ubuntu".

Если вы в ладах с английским — зайдите на IRC канал #ubuntu-testing и узнайте, не требуется ли какая-либо помощь с вашей стороны.

Помните: тестирование нового дистрибутива — это самый простой путь поблагодарить сотни людей, что трудятся над Ubuntu! Даже если вы ничего не найдёте это будет замечательно, значит новая версия дистрибутива действительно готова к выпуску.

Счастливого тестирования!

p.s. Пожалуйста, разместите это объявление у себя в блоге!

Продолжаем тему объектной модели данных. В этой части речь пойдет о модуле Data, являющимся, по сути, ORM системой. Для наглядности работы модуля Data c его помощью будет создано содержимое простого сайта. Предыдущая статья: Архитектура CMS. Модель данных. Часть 1.

Модуль Data состоит из классов Data, Object, Multy, Query и набора классов Cond*. Сам модуль – это статический класс Data, остальные классы используются для представления структур данных, с которыми он работает. Для представления сущностей в программном коде используется класс Object. Не важно, какого типа сущность – класс данных, объект данных или связь между ними – для всех Object. Класс Multy используется для ассоциации с набором сущностей, в частности, для представления множественных свойств. Классы Query и Cond* необходимы для осуществления поиска по объектной модели (в базе данных) с учетом гибких условий.

И был день третий, и задумался хабрапользователь-убунтоид: а как мне запаковать свой любимый пакет, чтобы был он красивый и правильный и чтобы гордость от его кошерности распирала ого-го как. Именно этим мы с вами сегодня и займёмся.
(Части 1, 2 и 4)

На второй день мы уже пообвыклись с идеей, что в дебиане и убунту любят действительно свободное программное обеспечение и уже начинаем задумываться о том, как бы нам начать собирать свой первый пакет. Но стоп! А какими программами мы вообще умеем пользоваться? Что?! OpenOffice.org Writer и Kopete? Не, ну так дело не пойдёт. Сегодня я расскажу вам обязательный минимум, который понадобится каждому будущему сопровождающему пакеты (я решил принять этот термин, оставив заморское слово «мэинтейнер» только в заголовке, как дань первой статье), да и просто любому убунтоводу пригодится в жизни.
(Части 1, 3 и 4)

Когда я прочитал эту и эту статьи, мне захотелось рассказать, как человек может внести свой маленький вклад в распространение своей любимой программы среди пользователей всеми любимой операционной системы. Полистав Убунтариум, я увидел, что статей на эту тему вроде бы не было, поэтому я решил смело приняться за дело.
(Части 2, 3 и 4)

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

Достаточно часто нам приходится хранить данные в memcached или MemcacheDB. Это могут быть относительно простые данные, например, закэшированные выборки из базы данных, а иногда необходимо хранить и обрабатывать более сложные структуры данных, которые обновляются одновременно из нескольких процессов, обеспечивать быстрое чтение данных и т.п. Реализация таких структур данных уже не укладывается в комбинацию команд memcached get/set. В данной статье будут описаны способы хранения некоторых структур данных в memcached с примерами кода и описанием основных идей.

Memcached и MemcacheDB в данной статье рассматриваются вместе, потому что имеют общий интерфейс доступа и логика работы большей части структур данных будет одинаковой, далее будем называть их просто «memcached». Зачем нам нужно хранить структуры данных в memcached? Чаще всего для распределенного доступа к данным из разных процессов, с разных серверов и т.п. А иногда для решения задачи хранения данных достаточно интерфейса, предоставляемого MemcacheDB, и необходимость в использовании СУБД отпадает.

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

Новичкам в Django будет полезно узнать об очень полезном инструменте отладки — debug-toolbar. Он настолько крут, что его называют Firebug for Django. На больших проектах без него (или другого отладчика) не обойтись.

Продолжаем ставить Xen на Ubuntu.
Часть первая

В комментариях к топику Системное администрирование. Начало. прочитал, что сообществу были бы интересны статьи о виртуализации. Довольно давно у меня на жёстком диске лежит описание процесса установки Xen hypervisor и гостевой ОС на сервер под управлением Ubuntu/Debian.

… пусть меня научат.

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

Введение и пара оговорок

Джаббер (Jabber) — протокол мгновенного обмена сообщениями. Хотя Jabber правильнее называть XMPP — расширяемый протокол обмена сообщениями и индикацией присутствия.

Это первая часть статьи из официального блога автора любимого всеми нами языка. Поэтому повествование ведется от лица самого Гуидо ван Россума. Вторая часть здесь.

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

Морфологический анализатор для русского языка — это что-то заумное? Программа, которая приводит слово к начальной форме, определяет падеж, находит словоформы — непонятно, как и подступиться? А на самом деле все не так и сложно. В статье — как я писал аналог mystem, lemmatizer и phpmorphy на Python, и что из этого получилось.

Уровень сложности: начальный

Вводный обзор стандартных инструментов GNU/Linux должен помочь начинающим пользователям Linux контроллировать работу ОС. Используемые приложения, как правило, включены в поставку известных дистрибутивов. Полезным побочным эффектом я считаю возможность сориентировать молодых системных и сетевых администраторов в условиях [подозрения] компрометации.

Безусловно, все те кто общается с ОС Linux хоть раз да имели дело(во всяком случае слышали точно) с командной оболочкой BASH. Но BASH не только командная оболочка, это еще и превосходный скриптовый язык программирования.
Цель этой статьи — познакомить поближе юзеров с bash, рассказать про синтаксис, основные приемы и фишки языка, для того чтобы даже обычный пользователь смог быстренько написать простой скрипт для выполнения ежедневной(-недельной, -месячной) рутинной работы или, скажем, «на коленке» наваять скриптик для бэкапа директории.

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



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

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

На хабре уже были топики, посвященные открытому API для работы с сервисом ruTube. В примере, который можно скачать с сайта ruTube (http://rutube.ru/partners/phpapi.html), отправка ролика осуществляется следующим образом (код взят из примера без правок):

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

Чем ближе Ваш сайт приближается к концепции Web2.0 тем больше JavaScript-кода появляется на Ваших страницах. Очевидно, что разработчику все больше времени приходится тратить на интеграцию своего серверного кода на php/java/python… с клиентской частью на JavaScript.

Большое количество кода требует какой-то систематизации, например, разнести логически связанные части кода по разным файлам, имена файлов привязать к контроллеру/событию/блоку… Наверняка у многих разработчиков есть свое решение этой проблемы.
На Хабре, например, JS-код разбит на небольшие блоки, которые запрашиваются в зависимости от страницы. Код написан красиво, откоментирован, стоят отступы. Небольшой минус такого подхода большое количество блоков (около 25) на каждой странице. В начале я использовал похожую схему, но сейчас, все же, хочу представить хабрасообществу немного другой подход.