Ну не скажите, откуда вам знать? Сейчас появляется много новых интересных проектов, которые со временем перетянут на себя часть аудитории, и карта изменится. Анализ динамических изменений — не менее интересная тема для размышлений, и сравнений с другими природными системами.
Замечательный проект!
Кстати, было бы интересно посмотреть на эту карту в динамике… Скажем с шагом, периодичностью в пару месяцев. С другой стороны, подобное исследование динамики может показать о стационарном состоянии системы, при отсутствии изменений в пределах нескольких лет.
Простите, я неправильно выразился. Речь идёт не о процедурных языках, а о всеми нами любимых объектно-ориентированных. Дело в том, что DCI позволяет избавиться от вопросов типа: «кому выгуливать собаку» или «не нарушу ли я инкапсуляцию, добавив в этот класс парочку гетеров-сетеров». Причём (следовательно) код становится более читаемым, поскольку большая его часть всё также выражена в простом процедурном стиле.
Хотя, на сколько я понял, основное ваше негодование было именно относительно того что объектно-ориентированный код не на 95% является таковым…
Тема конечно больная :) но многим ООП действительно таки помогает.
Если вы настолько восторгаетесь процедурными языками, и негодуете по поводу «не очевидного отражения сути ваших программ в коде», рекомендую к прочтению заметку о парадигме DCI (http://www.artima.com/articles/dci_vision.html) от товарища Трюгве Реенскауга (основоположника MVC). Возможно вы найдёте в ней то самое зерно, что сделает вас счастливым разработчиком (если вы конечно до сих пор не счастливы).
А можно ли обновлять только часть виджета в paintEvent? Т.е. перерисовывать не всё поле, а только те клетки, которые изменились? Понятно, что вы специально так не сделали… Вопрос о возможности как таковой.
Рассудите, правильно ли я понял, что действие предоставляемое ролью, само по себе является контекстом? Т.к. контект, по сути — это создание данных и инъекция в них методов. Конечно, можно обернуть данные и последовательность вызовов в контексте в отдельный класс, но это получается не всегда нужно делать.
Как может то, что предварительно компилируется в стандартные html и css, плохо поддерживаться браузерами?
В cms и фреймворки встраивать эти средства не так уж и сложно, и наверняка, если cms или фреймворк достаточно продвинутые — у них уже есть готовые плагины для использования scss и haml (ну или less). И даже если нету, то человек разбирающийся в структуре cms или фремворка, без особого труда сможет внедрить эти замечательные технологии в них.
Хотя конечно силами самого дизайнера — это сделать практически невозможно, и нужно прибегать к помощи программистов. Или сразу работать с нормальными фреймворками, априори поддерживающими данные технологии.
Жаль, что такие классные технологии как scss и haml так тяжко доходят до людей. А ведь они существенно облегчают жизнь, отстраняя от мысли о том, что «я хочу новый стандарт html».
Тут скорее проблема в том, что в большинстве официальных линуксовых репозиториях, до сих пор лежит Ruby 1.8. Хотя конечно, для тех кто в теме, RVM решает все проблемы, но поверьте есть и те, кто не в теме.
Кстати, было бы интересно посмотреть на эту карту в динамике… Скажем с шагом, периодичностью в пару месяцев. С другой стороны, подобное исследование динамики может показать о стационарном состоянии системы, при отсутствии изменений в пределах нескольких лет.
Хотя, на сколько я понял, основное ваше негодование было именно относительно того что объектно-ориентированный код не на 95% является таковым…
Тема конечно больная :) но многим ООП действительно таки помогает.
Спасибо.
И ещё отдельный респект за продвижение мысли о руби и рельсах в массы русской души :)
Выглядит очень вкусненько. Давно сам подумывал о нечто-подобном. Но вы сделали всё — ещё красивше.
Спасибо!
Даёшь нативную поддержку браузером scss и haml!
В cms и фреймворки встраивать эти средства не так уж и сложно, и наверняка, если cms или фреймворк достаточно продвинутые — у них уже есть готовые плагины для использования scss и haml (ну или less). И даже если нету, то человек разбирающийся в структуре cms или фремворка, без особого труда сможет внедрить эти замечательные технологии в них.
Хотя конечно силами самого дизайнера — это сделать практически невозможно, и нужно прибегать к помощи программистов. Или сразу работать с нормальными фреймворками, априори поддерживающими данные технологии.