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

Именно тогда-то и появилась мысль написать автоматический генератор заданий. Про генератор одного из заданий я и расскажу ниже.

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



Я хочу поговорить о том, как вставлять диаграммы на страницы вики (под словом вики в этой статье подразумевается исключительно MediaWiki). Стандартный подход — хранить диаграммы в файлах внутри самой вики — имеет свои недостатки; о них — под катом. Я попробовал использовать Graphviz — инструмент, который сам рисует графы по заданным данным. Вот исходник картинки, с которой началась эта статья:

digraph A {
Feedback -> New_Assigned [dir="both"];
New_Assigned [label="New / Assigned"];
New_Assigned -> Rejected [dir="both"];
Reopen -> Rejected;
Reopen -> New_Assigned;
New_Assigned -> Resolved -> Testing -> Approved -> Closed;
Testing -> Closed;

{ rank=same; Feedback; Reopen; }
{ rank=same; Resolved; Testing; Approved; }
}


Прочитав книжку Р. Мартина «Чистый код», я исполнился решимостью и принялся за рефакторинг своего старого, большого и грязного проекта.

И захотелось мне посмотреть, как в одном из самых простых классов связаны между собой методы и поля. PhpCallGraph, быстро нагугленный, наладить не удалось (какие-то проблемы с xdebug), и к тому же, судя по примерам, он показывает связи во всём проекте, трассируя его, а мне нужно было исследовать один класс.

Я решил написать собственное решение, и вот что получилось.

В ноябре 2010 года появилась Яндекс.Мастерская. Этот возможность для студентов принять участие в проектах и задачах, которые в перспективе могут быть внедрены для внутренних или внешних пользователей Яндекса. В Яндексе давно практикуется набор стажёров, но обычно только на роль разработчиков или тестировщиков. В Мастерской же способные ребята могут проявить себя ещё и в области аналитики и управления проектами.

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

Поэтому, если ваш проект на Django, то получать актуальную архитектуру БД вашего приложения за несколько секунд поможет вот такое вот дополнение: django-graphviz (ссылка)

Пример того, что получается на выходе(с официальной страницы):


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

Для django есть хорошая утилитка, которая анализирует описание модели данных и рисует её графическое представление в dot-формате graphviz.
Сегодня переписал эту утилитку под appengine.



Утилита распознаёт Expando (добавляет многоточие в список атрибутов),
наследование от PolyModel (рисует стрелки наследования),
а также ссылочные свойства (в том числе самодельные, типа ManyToManyProperty).

Как пользоваться:

1. засунуть скрипт в каталог с sdk
2. запустить её из корневого каталога приложения, указав аргументами список модулей для анализа (в формате имён дя import):
   python path/to/modelviz.py models.foo models.bar > models.dot
3. сконвертить полученный dot-файл во что-нибудь более удобное, например, в png:
   dot models.dot -Tpng > models.png
4. наслаждаться неземной красотой

Добрый вечер Дорогие друзья!

Недавно, прогуливаясь по просторам бескрайнего интернета, я наткнулся на изумительные работы Криса Харрисона, посидев немного в шоке, я подумал «А сложно ли визуализировать википедию или нет?» и решил попробовать!



Итак, приступим!

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

В начале мая этого года в разговоре с коллегой по работе (в ходе обсуждения одной задачи на практическое применение множеств) вспыл вопрос о построении связей между объектами одного сайта. Этот сайт представлял собой каталог аналогов Windows и Linux программ, и одной из «фишек» этого каталога была выборка ПО по разделам а-ля фасет (визуально фасет, а внутри все на множествах реализовано насколько я понял из обсуждения (реализацию сайта делал другой человек – нужно будет еще и с ним обсудить этот вопрос)). В общем говоря я несколько удивился задаче и… заявил, что она довольно тривиальна, и если при проектировании базы данных связи между таблицами делать как многое-к-многому, то решается все одним запросом. Поговорили и разошлись, но идея сидела в подсознании и долбила «можно же и лучше сделать».