Некоторое время назад я опубликовал очень многословное сочинение, где пытался объяснить, почему Git серьёзно поломан, и почему всем следует вместо этого пользоваться Mercurial, до тех пор, пока разработчки Git его не починят. Ну ладно, я был не настолько груб, но близок к этому.

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

Ниже я нарисовал упрощёный граф истории репозитория Git с тремя созданными ветками: «master», «release» и «topic». До того, как энтузиасты Git начнут ругаться, что я исхитрился показать нереально плохой случай запутанности истории, позвольте мне заверить вас, что это на самом деле ещё упрощённый пример. У меня есть доступ к реальному репозиторию Git, где создано шесть рабочих веток релизов, около сорока рабочих тематических веток и несколько сотен ранее существовавших веток, которые уже удалены с центрального сервера.

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

В проекте панели управления хостингом, разработкой которой я занимаюсь значительную часть времени своей работы в NetAngels, насчитывается 120 таблиц и при тестировании загружается порядка 500 объектов из fixtures. Нельзя сказать, что это пугающе много, однако создание всех таблиц, добавление индексов и загрузка объектов при каждом запуске теста довольно сильно напрягают, особенно, если запускается всего один или пара тестов.

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

Краткий обзор

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

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

Хочу начать с того, что мне жутко надоели презентации со стандартным лейаутом: сверху шапка с темой, потом набор пунктов, снизу футер ну и справа и/или по центру картинка может какая-то или диаграмма.

Скучно!

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

Привет. В этой серии постов я попробую рассказать про тестирование кода на питоне, в частности проектов django. Мы рассмотрим модульное тестирование (юнит-тесты), статический анализ кода и некоторые подводные камни тестирования веб-сайтов.

Вводную часть о пользе тестирования опустим — код, покрытый тестами, становится мягким и шелковистым, про это только ленивый еще не читал / писал.

В Сети можно обнаружить массу советов, статей и FAQ для web-маcтеров, которые посвящены теме взаимодействия сайтов и поисковых систем. Поэтому принципиально нового в идее schema.org, конечно, нет. На нем собрано (пока довольно небольшое) число примеров рекомендуемой HTML-разметки и некоторой другой полезной информации, использование которой web-мастерами позволит создавать «правильные» сайты, анализ которых поисковыми системами будет наиболее быстрым и эффективным, что, в свою очередь, позволит пользователям быстрее находить интересующую их информацию.

Более любопытным является то, что создателями сайта являются три крупных игрока IT-рынка, для двух из которых область интернет-поиска является, как минимум, ключевой в их бизнесе. Сайт создан Google, Yahoo! и Microsoft и, признаться, не часто приходиться видеть объединение конкурирующих компаний в деле, которое реально может быть полезным для обычных пользователей сети.

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

Вступление

Kango позволяет создавать расширения для популярных браузеров используя только JavaScript, причем код един для всех браузеров. На данный момент поддерживается Chrome, Firefox, Internet Explorer (в публичном доступе только версия с поддержкой Chrome и Firefox) и ведется работа над поддержкой Opera и Safari. Ниже будет рассмотрено как можно быстро создать простой кроссбраузерный Gmail Checker

Что должно получиться в итоге:

Хочу поделиться опытом настройки сервера для django-проектов. Так вышло, что мне часто приходится настраивать с нуля VPS-сервера для запуска на них django-сайтов. Как-то мне в голову пришла идея записать пошагово процесс настройки. Оказалось, что “по бумажке” выполнять эти рутинные операции гораздо проще и быстрее — все нюансы записаны, трудно что-то упустить. Дальше больше — я превратил инструкцию в самостоятельный shell-скрипт — запустил и сервер готов. Я думаю, некоторым python-разработчикам, особенно начинающим, будет полезно ознакомиться с содержимым скрипта. С некоторыми доработками вы, возможно, захотите использовать его в своей практике.

Этот плагин позволит вам легко и элегантно выводить сообщения и небольшие формы в ваших веб-проектах, построенных на Mootools.

Основные характеристики

1. Полнофунциональные диалоги. А значит из коробки работают модальность, многооконность, закрытие по Esc, перетаскивание, растягивание (опционально), удобный механизм добавления кнопок и другие вкусности. При этом все очень ненавязчиво.
2. Простой API для кастомизации и манипуляции диалогами.
3. Стилизация через CSS, что означает что многие, если не все свойства связанные с внешним видом и даже некоторые связаные с поведением можно переопределить в своих CSS файлах, а значит вы легко впишете диалоги в стиль своего проекта (см. примеры).
4. События позволят вам перехватывать ключевые моменты поведения диалогов и дополнять их собственным поведением.
5. Работает из коробки с MUX.Loaders, но не требует их если вы не хотите их использовать. Просто подключите файл лоадеров до диалогов и все — анимация сама запустится перед событием submit и остановится при закрытии.
6. Полная документация и примеры.

Проект на github https://github.com/lavmax/MUX.Dialog.

Тестировалось на IE7+, FF3+, Chrome, Safari, Opera последних версий.

Некоторые примеры использования и кастомизации

Взаимодействие частей приложения друг с другом — важная часть архитектуры любой программы.
И существует немало паттернов для их реализации. Я бы хотел на примере веб-приложения показать применение одного из них, а именно — Event-driven модели.
Она хорошо известна любому frontend-разработчику — всякий раз, работая с событиями DOM, вы используете эту модель. Давайте попробуем построить на ней не маленькое веб-приложение — файловый менеджер.

Доброе время суток, дорогой %username%.

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

Под катом общие размышления, обзор текущего состояния проекта, перспективы и, конечно, немного трафика.

Если интересно — welcome под кат.

Тема автоматического реферирования/аннотирования текста была поднята давно и было придумано множество способов ее реализации. Так как желание знать главное есть у всех, но это, как правило, связано с просмотром множества материалов.

Готовые библиотеки найти не так легко, а то, что есть, слабо конфигурируется, не доделано и, главное, работает только для английского языка. Я захотел исправить этот недостаток и вот что получилось.

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

Извращаться приходилось всем: не только пользователям джанги, но и самим её core-разработчикам. Помните, например, как в Django 1.2 внезапно стало возможно использовать в поле username символы собаки (@) и точки? Знаете зачем? Чтобы в качестве логинов можно было использовать адреса e-mail.

Нам, простым пользователям, тоже жилось несладко. Для того, чтобы изменить профиль пользователя, добавив ему какие-нибудь интересных полей — обычная, казалось бы, вещь, да? — приходилось действовать разными способами.

Наглядное представление популярных Open Source лицензий

Для краткости, введем обозначение «нестандартные» — под этим термином будем далее подразумевать такие модули, которые содержат в себе файлы, отличные от *.py. К примеру это могут быть библиотеки (*.pyd), картинки, иконки, и т.д.

Первая проблема состоит в том, что практически все сборщики бинарных «дистрибутивов» python-приложений, такие как py2exe, bbfreeze, cx_Freeze, и другие, забирают из таких модулей только *.py файлы. Вторая проблема возникает со сложными namespace-модулями, такими как ETS — часто сборщик не может правильно разобрать все их внутренние зависимости.

Конкретно в моем случае камнями преткновения оказались все модули ETS (mayavi, chaco, и т.д.), m2crypto, vtk, h5py, matplotlib и несколько других (вообще, как выяснилось, таких модулей очень много).

Я попробовал протестировать разные сборщики и поначалу остановился на cx_Freeze, т.к. он единственный умеет более-менее правильно импортировать ETS «из коробки». Однако, его оказалось недостаточно: он не смог справиться с другими нестандартными модулями, а также по ряду других причин (к примеру, мне так и не удалось скрыть окно консоли, поставить кастомную иконку, и пр.). Конечно, там есть механизм «рецептов» (совсем не документированный), который даже работает, к примеру, для matplotlib, но хотелось более универсального и простого решения, чем писать подобный рецепт под каждый модуль.

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

Доступность контента и отображение информации на сайте чрезвычайно важна. Говоря простым языком, что хорошего может сделать то, что находится у вас на сайте, если определенные люди не смогут увидеть это? Конечно, этот новый модный дизайн с мелким шрифтом и малоконтрастными цветами для вас и ваших друзей выглядит классно, но вот что насчет тех, у кого слабое зрение, или тех, кто не различает некоторые цвета, или тех, у кого какие-либо другие проблемы со зрением — они ведь просто не смогут ничего найти, не говоря уже о том, чтобы прочитать хоть что-нибудь на вашем сайте. Вам надо, даже не «надо», а вы ДОЛЖНЫ сделать свой сайт доступным для как можно большего числа посетителей.

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

Введение

Коллеги, при разработке приложений, мы каждый день сталкиваемся с потребностью в гибком хранении информации (обновлении, поиске по ней, и т.д.). Класс продуктов, которые решают этот круг задач, как все мы знаем — Базы данных. Но что это такое в нашем понимании? У многих «база данных» твердо ассоциируется с MySQL, таблицами и SQL-запросами. И это устраивает до определенного момента. Действительно, реляционные базы данных дают массу преимуществ в работе: поскольку данные имеют сильную связанность, не нужно контролировать целостность базы данных. Используя простой под-запрос можно выбрать количество комментариев к каждому посту в блоге. Используя JOIN нетрудно делать сложные связанные выборки и получать данные сразу о нескольких сущностях.

Несмотря на наличие «Rails 3» в названии топика, и рассмотрения в теле статьи специфичных для Rails 3 аспектов, она может быть интересна всем остальным из-за освещения аспектов общего характера.

На Хабре много ответов на разные мои вопросы, но ответа на вопрос «а где же мне хостится», получить я, даже при внимательном штудировании Хабра, не смог. Я даже воспользовался q&a, пытаясь определиться: раз и два, но окончательного ответа так и не получил. Пришлось проводить самостоятельное исследование.

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

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

Список упоминаемых хостингов: 1gb.ru, Hostingrails, RackspaceCloud, Mediatemple, Heroku, Amazon Web Services (шапочно), Engine Yard (шапочно), Altnet (привет с Хабрахабра), justhost.com (лучи поноса), Linode, Hetzner online (выделенный сервер), Server4you

Просто и быстро

Не так давно я столкнулся с необходимостью запротоколировать список изменений в нашем ПО. Заказчик прислал мне формуляр, который я должен был заполнить в соответствии с их внутренними требованиями к документации. Я открыл прилагавшийся к письму файл «Изменения 1.xls» и немного приуныл. Точнее, мне в голову последовательно пришли мысли об увольнении, а затем — о самоубийстве. Формуляр состоял из 14 колонок. Быстро перемножив в уме количество колонок с числом внесенных нами атомарных изменений (около пятисот), я пошел курить.
Сделать такую работу руками мне не под силу. Большинство данных (номера новых версий, описания изменений и т. п.) у меня, конечно, имелись в наличии, но в разных местах и самых причудливых форматах. Но семьсот копипастов — увольте. Поэтому мне пришлось немного освоить PyUNO. На всякий случай — опишу вкратце процесс управления документом OOo из питоновского биндинга, вдруг кому пригодится.

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

Точек зрения на то, каким должен быть сайт, много: у программиста одна, у дизайнера – другая, у интернет-маркетолога – третья, у владельца…

На самом деле, точка зрения – всего одна – у конечного пользователя ресурса. И именно это в первую очередь нужно учитывать. Естественно, принимая во внимание удобство обслуживания сайта администратором.

В чем преимущества грамотно написанного технического задания:

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