Как много веселых ребят
И все делают велосипед.
А один из них как-нибудь утром
Придумает порох.
Виктор Цой.



Сначала я хотел написать в раздел «Я пиарюсь» статью о том какой я молодец и какую замечательную штуку сделал но, немного поискав в сети, я без удивления обнаружил, что я совсем не единственный в своем роде. Тогда я решил пойти от обратного: наверное, практически каждый Веб-программист хотя бы раз в своей жизни пытается написать полноценную CMS. При этом, в процессе проектирования (а это процесс, зачастую, наступает уже во время написания кода) у разработчика непременно возникают вопросы. С этими вопросами он обращается к поисковикам и попадает на сайты тех, кто по подобным граблям уже прошествовал.

Итак, я стал смотреть, по каким же запросам попадают ко мне начинающие «разработчики велосипедов», и постарался осветить некоторые вещи, которые для меня самого были неочевидны в начале работ.

Поскольку новость не пробежала на Хабре, но однозначно (с) будет интересна многим:

«Видео с пользовательской конференции по Sphinx (~8часов)
http://devconf.tv/user/sphinx».

Добрый день, %username%!
За последний год столкнулся с несколькими задачами по написанию SOAP/REST API к различным сервисам и вывел для себя боле-менее удобную модель. Я не претендую на фундаментальное исследование, просто хочу поделиться опытом наступания на грабли.

Для начала общие требования к default API:

• возможность расширения
• удобный стандартизированный формат запросов
• удобный стандартизированный формат ответов
• достаточный уровень безопасности
• возврат ошибок выполнения запроса

Все мы прекрасно понимаем, что тестирование является неотъемлемой частью жизненного цикла разработки ПО. Чем чаще мы тестируем наш код, тем быстрее мы сможем обнаружить ошибку, вкравшуюся в него в ходе разработки, и быстрее её исправить. При этом стоит понимать, что тестирование крайне желательно проводить в окружении, максимально близком к боевому (ОС, ПО, Hardware, Нагрузка), что бы иметь возможность обнаружить ошибки, которые не проявляются на сервере разработки, но могут появиться в бою. Компануя два вышесказанных тезиса вместе мы получаем концепцию, называемую Continuous Integration.

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

Для автоматизации процесса непрерывной сборки существуют готовые решения (Hudson, CruiseControl), интеграцию одного из которых (Hudson) я и опишу в этой статье.

Hg Init: Учебное пособие по Mercurial.

Mercurial — это современная распределенная система контроля версий с открытым кодом. Эта система — заманчивая замена для более ранних систем вроде Subversion. В этом простом учебном пособии в шести частях Джоэль Спольски (Joel Spolsky) рассказывает о ключевых принципах Mercurial.

Если вы использовали Subversion, то Mercurial будет непонятным. Эта часть рассказывает о главных отличиях при работе с Mercurial. Если вы никогда не использовали Subversion, то можете просто пропустить эту часть.

Часть 1. Переобучение для пользователей Subversion

В каком же я был смятении, когда программисты в моей компании решили сменить Subversion на Mercurial!

Для начала, я начал приводить всевозможные тупые причины, по которым нам не надо ничего менять. «Мы должны хранить репозиторий на центральном сервере, так безопаснее», — сказал я. Знаете что? Я был неправ. При работе с Mercurial у каждого разработчика на жестком диске хранится полная копия репозитория. Это, на самом деле, безопаснее. В любом случае, почти в каждой команде, использующей Mercurial, центральный репозиторий тоже существует. И вы можете делать резервное копирование этого репозитория со всей необходимой одержимостью. А еще можете устроить трехступенчатую защиту с Сайлонами, Штурмовиками и прелестными лабрадудлами или что там требует ваш IT-отдел.

Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».

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

Часть 2. Основы Mercurial

Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:

1. Она хранит все предыдущие версии каждого файла
2. Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения

День 16 ноября 2010 года навсегда войдёт в историю Creative Commons в России. В этот день по предложению вашего покорного слуги на официальном сайте Creative Commons появились русские переводы т.н. «Commons Deed» (краткого объяснения лицензий). Так как русский язык на территории бывшего СССР является lingua franca, теперь все русскоязычные люди из бывших республик могут легко понимать условия лицензий Creative Commons! Пожалуйста, обновите ссылки в ваших проектах (в Википедии ссылки уже обновлены).

• Creative Commons Attribution 3.0 Unported
• Creative Commons Attribution-ShareAlike 3.0 Unported
• Creative Commons Attribution-NoDerivs 3.0 Unported
• Creative Commons Attribution-NonCommercial 3.0 Unported
• Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported
• Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported
• CC0 (CCZero)
• Public Domain Mark
• Copyright-Only Dedication* (based on United States law)
  or Public Domain Certification

Белорусские переводы также доступны.

Взгляд в будущее

    В последнее время всякие социальные сети и вообще сервисы-лидеры интернета по посещаемости и количеству аккаунтов завели очень неплохую, на мой взгляд, привычку — предоставление уникальных OpenID-идентификаторов для пользователей, дабы с их использованием можно было зайти на сторонний сайт. Кроме того, параллельно развивается очень похожая, но все-таки не совсем производная технология OAuth, которая появилась на свет благодаря стараниям создателей небезызвестного Twitter и, цитируя википедию, «позволяет предоставить третьей стороне доступ к защищенным ресурсам пользователя, без необходимости передавать ей (третьей стороне) логин и пароль».
    Лично меня такая тенденция очень радует и, более того, я почти уверен, что за подобной технологией будущее. В частности, в будущем обязательно появятся новые мэшапы для агрегирования информации с кучи сайтов (в частности, хочется вспомнить очень хороший, но несправедливо забытый сервис Yahoo Pipes, который так и не смог покорить сердца и умы просто потому, что его время тогда еще не пришло. Возможно, все еще впереди), а именно такой «форм-фактор» требует логина на кучу сервисов сразу.

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

Возникла задача написание простенького расширения под все (по возможности) популярные браузеры. Деятельность расширения заключается во внедрении javascript`а в тело документа.

Наши пользователи следят за спецпредложениями авиакомпаний и дешевыми перелетами, каждому интересно своё направление, пунктов вылета и прилета — тысячи, пользователи хотят одновременно следить за несколькоми городами, странами или регионами. Появилась задача — как предоставить удобный механизм подписки? Без долгого тыканья в мульти селект, без кнопок «Добавить пункт вылета». Ответ выглядит так —

Решением стал контрол из Фейсбука и Контакта — пользователи знакомы с ним, а значит не нужно объяснять как он работает. Осталось скрестить его с django.

Топик навеян впечатлениями от докладов на swpiter и постом о том, как не продать машину :)

Как работать над стартапом и всегда оставаться в выигрыше?

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

Картинка слева кликабельна, а ниже — текстовое описание в 12 шагах как инициировать стартап и при этом всегда оставаться в выигрыше.

1. Идея!

И так, всё начинается с идеи, которая каким-то образом пришла к вам в голову. Идея выглядит интересной и соблазнительной. Она мотивирует вас.

Самое важное в идее — это не терять мотивацию вплоть до 10 шага и тогда вы в любом случае получите для себя выгоду.

2. Детализация идеи

Необходимо хотя бы примерно ответить на эти вопросы:

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

На этом этапе ещё рано отвечать на вопросы:

• сколько времени вы можете уделить (если идея вас реально интересует, вы перейдёте к следующим этапам)
• сколько на это нужно денег
• кто вам ещё нужен для реализации идеи

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

Проблему можно представить графически так:


Задача вёрстки заключается в следующем:

• — независимо от разрешения (размера она браузера), информативная часть сайта находилась посередине;
• — справа и слева должны остаться графические блоки (уши), причём эти уши должны быть видны только при увеличенном размере экрана браузера, а при уменьшенном не уместившаяся часть должна прятаться (в идеале, чтобы ещё горизонтальной полосы прокрутки не было);;
• — страница должна быть резиновой от 680px до 1000px.

Работает для FF3, FF4, IE8 и почти для Opera.

Перевод статьи Vincent Driessen: A successful Git branching model

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



В качестве инструмента управления версиями всего исходного кода она использует Git.

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

Традиционная картинка для привлечения внимания:

Алгоритм Флойда — Уоршелла — алгоритм для нахождения кратчайших расстояний между всеми вершинами взвешенного графа без циклов с отрицательными весами с использованием метода динамического программирования. Это базовый алгоритм, так что тем кто его знает — можно дальше не читать.

Этот алгоритм был одновременно опубликован в статьях Роберта Флойда (Robert Floyd) и Стивена Уоршелла (Stephen Warshall) в 1962 г., хотя в 1959 г. Бернард Рой (Bernard Roy) опубликовал практически такой же алгоритм, но это осталось незамеченным.

Накопилось несколько маленьких заметок/советов про python и django, которые на отдельные топики не тянут, поэтому публикую все сразу.

Под катом:

• как упростить код вьюх ровно в 2 раза
• легкий способ рисования графиков
• почему Ian Bicking воскликнул «Cool!»
• приложения для ВКонтакте на django за 5 минут
• хорош ли pymorphy?
• пара фишек насчет выкладки пакетов на pypi
• что общего между декораторами и with-контекст-менеджерами
• принимаем оплату на django-сайтах
• показываем Яндекс.Карту для заданного адреса

Добрый день!

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


Большинство лекций читается на русском языке. Все записи снабжены презентациями и описаниями.

UPD. Кратко. Старые лекции в плохом качестве, а новые с 2010 года с хорошим звуком и в 720p.
UPD 2 Расширили канал, видео грузится теперь без проблем.

Под катом перечень курсов и несколько вопросов касательно вебинаров.

Добрый день, Хабрахабр. Это еще один пост в рамках моей программы по обогащению базы данных крупнейшего IT-ресурса информацией по алгоритмам и структурам данных. Как показывает практика, этой информации многим не хватает, а необходимость встречается в самых разнообразных сферах программистской жизни.
Я продолжаю преимущественно выбирать те алгоритмы/структуры, которые легко понимаются и для которых не требуется много кода — а вот практическое значение сложно недооценить. В прошлый раз это было декартово дерево. В этот раз — система непересекающихся множеств. Она же известна под названиями disjoint set union (DSU) или Union-Find.

Условие

Поставим перед собой следующую задачу. Пускай мы оперируем элементами N видов (для простоты, здесь и далее — числами от 0 до N-1). Некоторые группы чисел объединены в множества. Также мы можем добавить в структуру новый элемент, он тем самым образует множество размера 1 из самого себя. И наконец, периодически некоторые два множества нам потребуется сливать в одно.

Формализируем задачу: создать быструю структуру, которая поддерживает следующие операции:

MakeSet(X) — внести в структуру новый элемент X, создать для него множество размера 1 из самого себя.
Find(X) — возвратить идентификатор множества, которому принадлежит элемент X. В качестве идентификатора мы будем выбирать один элемент из этого множества — представителя множества. Гарантируется, что для одного и того же множества представитель будет возвращаться один и тот же, иначе невозможно будет работать со структурой: не будет корректной даже проверка принадлежности двух элементов одному множеству if (Find(X) == Find(Y)).
Unite(X, Y) — объединить два множества, в которых лежат элементы X и Y, в одно новое.

На рисунке я продемонстрирую работу такой гипотетической структуры.

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

Замечательный сайт www.sorting-algorithms.com позволяет увидеть, как сортируются данные разными алгоритмами. Вы сможете посмотреть анимацию в зависимости от алгоритма, исходных данных.



Все это бегает и сортируется прямо на ваших глазах!

Работает на Google App Engine, видимо, поэтому и лежит от посетителей с «Хабра».