Публикации с меткой «архитектура»

Блог python на хабрахабре

Python / Антипаттерн settings.py



Хабрапитонерам привет!

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

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

Итак, почему же такой подход на мой взгляд отвратителен.

Ростислав Дзинько

Размышления об идеальной архитектуре приложения. Часть 2: Развеиваем мифы?

Содержание

Часть 2

Пролог
Прошло уже несколько дней с момента публикации первого поста по данной теме. Ух и наслышался я о себе за это время, ну, не так о себе, как о моей идее. К сожалению все "Фу..." не пошло в комментарии. Кто-то писал мне в скайп и джаббер, кто-то - плюнул в лицо при личной встрече. Подведя итог: все усомнились и поулыбались. Но... Многие, судя по комментариям так и не поняли, что я хочу донести, то есть неправильно поняли суть решаемой задачи, и сейчас я это хотел бы исправить. Это скорее моя ошибка, да еще терминатор подогрел.

И в конец пролога - угадайте, что же это за такой талантливый инженер изображен на фотке справа :)

Я не пытаюсь создать универсальное средство решения задач
Это коренное заблуждение, которое я увидел в комментариях к моему посту. Универсальное средство решение - есть наш мозг. Но самый занятный момент здесь в том, что он не предназначен напрямую решать задачи. Схему его работы скорее можно представить как: "научится решать" -> "решить". А в нашее время еще и создать средство для того, чтобы задачу, которую мы научились решать - решал кто-то другой. Например, арифметические операции прекрасно выполняет калькулятор.

К чему я веду?
Я веду к тому, что я хочу создать не фреймворк, который решает все задачи (то есть это не универсальная нейросеть, и никакой другой универсальный апарат решения задач), - это уже не будет фреймворк, а "кнопка" "Сделать зашибись". Я хочу создать фреймворк реализующий архитектуру (подход, методологию) приложения, которую можно применить для всех задач.
Привожу пример
практически все боьшие коммерческие компьютерные игры создаются на объектно-ориентированных языках (в основном это С++). Попытка сделать игру пользуясь только структурным подходом приведет сами понимаете к чему.
Но какой занимательный факт. Ведь имея, например, в своем распоряжении, грубо говоря, функцию main (рассмотрим вариант на С), мы можем написать любое приложение:
int main() {
// Do any task in the world
return 0;
}
То есть, по сути, вот оно! =) Отсутствие фреймворка, каких-либо архитектурных правил и ограничений и привело нас к цели. Пользуясь таким "фреймворком" можно сделать все.

Смешно, да?
Действительно, понаписывал про терминаторов, про всякую фигню и дошел до того, что фреймворки нафиг не нужны. Не совсем так.

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

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

Заключение
Дела с покорением мира обстоят немножко плохо, но, благодаря уверености Андрея Светлова в том, что задача более легкая и обозримая, как-нибудь к ней вернусь, может даже напишу о прогрессе здесь.

Надеюсь, что внес некоторую ясность в идею, изложенную в предыдущей публикации, если не запутал вас еще больше :)

Ростислав Дзинько

Размышления об идеальной архитектуре приложения. Часть 1: Возможно ли это?

Содержание

Часть 1

Пролог

Нет, здесь я имею в виду не язык программирования, а именно вступление к публикации. И терминатор здесь как нельзя кстати, потому что мы будем решать именно задачу построения "Терминатора", как минимум T-100, а дальше как пойдет. Ко всем уважаемым читателям есть огромная просьба выполнять следующие пункты:
  • читать пост до конца
  • если не читаете до конца - просто забейте, и не пишите комментарии.
  • если уж собрались писать, не задавайте, пожалуйста, вопросы о моем возрасте, цвете волос и прочем :)
  • я на них отвечаю тут: мне на момент написания статьи - 21 год, учусь на 5-м курсе института, цвет волос каштановый...
  • на посты типа: "это нереально", отвечаю тут же известной эмпирически созданной формулой группой ученых, пытавшихся создать контроллируемый ядерный взрыв: "энтузиазм = 1/опыт".
Так, с прологом разобрался, всех остальных милости прошу дальше...

Постановка задачи

Тем, кто во время чтения пролога забыл, в чем суть задачи, напоминаю, и переформулирую:

"Существует ли идеальная архитектура приложений, и можна ли создать фреймворк годный для решения всех-всех-всех задач программной инженерии?"

Вот это постановка вопроса! Да? Существует ли ответ на этот вопрос?
Ну, судя по наличию языков программирования, фреймворков и решений... наверное, пока нет.
Стоит ли работать над этим? То есть, стоит ли искать такое решение?
Предположим, что да. Зачем тогда я тут стучу пальцами по клавиатуре?
Являются ли все существующие решения этим самым поиском?
Осмелюсь сказать, что нет. Есть множество шаблонов проектирования, рекомендаций на все случаи жизни, архитектур, и еще много умных слов, аббревиатур, которые успешно и неуспешно используются при создании приложений.
Почему?
Каждый инженер-разработчик работает в своем кругу задач. Общее множество задач растет с каждым днем с развитием аппаратных и программных платформ, поэтому эти самые инженеры-разработчики работают с каждым днем с более узким кругом задач (если брать отношение мощности множества задач к общему множеству всех-всех-всех возникающих задач). То есть, из это следует, что на самом деле мы не приближаемся к решению, а отдаляемся от него.
Пути решения

Если попытаться приближаться к решению, мы стыкаемся с двумя принципиальными моментами:
  1. Тот, кто решает данную задачу, должен набить руку в большом круге областей задач (в идеале на всем множестве возникающих инженерных задач компьютерных наук), и должен быть знаком с лучшими (предпочтительными / идеальными) решениями этих задач. Потом найти пересечение множеств всех подходов к решению задач, и... вуаля! В чем проблема? Наверное в том, что никакой жизни не хватит такой опыт получить :)
  2. Исходя из предыдущего пункта, напрашивается вывод, что с практической стороны подход невозможен, и решать эту задачу (создавать фреймворк) нужно призывая теоретический подход. Хорошо это? Ну, как показывает практика, 100 500 подводных камней могут возникнуть, и, собственно, возникают. Как их избежать?
Выбор пути

Из вышесказанного можно предположить, что только второй путь, по крайней мере, кажется не невозможным. Что я предлагаю? Я предлагаю пойти этим путем, принимая только "аксиоматические" мысли, и отбрасывая спорные. То есть поступать примерно так, как это делают математики: "Определяем аксиомы, на их основе строим теоремы, и доказываем их".

Выводы

Идельной универсальной архитектуры приложений нет ... Пока... Почему-бы не попытаться ее создать? На Python, конечно, на чем же еще? :) "There should be one-- and preferably only one --obvious way to do it." Может, он существует, путь этот, неизбитый?

Благодарности

Особую благодарность хочется выразить моему другу Дмитрию ака semargl89, при участии которого эта злостная публикация появилась, и который со всем написанным согласен :), но требует деталей и продолжения, и участвует в дискуссиях составляя мне оппозицию.
To be continued... maybe soon... maybe later... maybe sometimes...
P.S
Минуту назад зафоловил Шварценеггера в Твиттере :)

Метки

.net .NET C# .sort 1.2 2009 2010 404 error admin ajax amazon analytics and apache api archlinux asp.net async asynchronous autocomplete bash blender blog blogengine blogs book bootstrap bot bpython buildout byteflow bzr C c plus plus C++ cache cbv Chaco checkio chrome ci ckeditor class based views clojure closure cms cms с удобной админкой code coding style collectd COM comet competition conference ConfigParser contest Context continuous integration CouchDB coverage CppCMS cpyext cpython crud csrf CSS ctypes curl custom model fields cx_freeze cython database db dbm dbqueries debian debug debugging decorator decorators deploy deployment descriptor design dev devconf developers development diveintopython Django django 1.2 django 1.3 django advent django framework django template django trunk django weblog django-admin-tools django-cms django-compressor django-hosts django-piston django-registration django-sphinx django.admin djangoadvent djangocms djangodash doc documentation drupal e-legion eclipse EGit emacs encoding Enthought epoll erlang event exception ExtJS fabric facebook fastcgi finaloption fixtures fonts forms formset fp framework freebsd freeswitch fs2web ftp fun funcparserlib functional gae gamin gandi generic views gettext gevent gil git github gitosis Google Google App Engine google picasa Google Translate google wave Google Web Toolkit grab grablab greenlet gtd gui haskell hg hgshelve highlighter host hosting how-to howto html html5lib Hudson humor i18n icfpc ide idiomatic image-scripting improvements Internet interpreter ipython ironpython izmenimsya.ru jabber java javascript jenkins jetbrains JIT job jquery json jstree jython kde kiev kiyv kyivpy l10n ldap library libs Life Links linux Linux & Unix LLVM logging logs lxml Mac OS X magic mail markdown Matplotlib Mayavi maybe mediavirus meetup memcache Memcached memory messages metaclass middleware migration mikrotik mkd model models mod_python mod_wsgi mongodb monitoring mptt musicmans.ru musicx mvc my-projects mysql netCDF networkx newforms newforms-admin news nginx Nhibernate nix nose NoSQL numpy oop open source OpenID openoffice opster optimization oracle orm os pagination parsing path patterns pdf PDF-принтер PEP PEP8 performance performance optimization perl personality photo php picture-driven computing PIL pinax pingback pip plasma plone plugin plugins postgresql programming progress bar psycopg2 py2exe pybb pybbm pycamp pycharm pycon pycow pycurl pydev pygtk pylons PyNGL pypy pyqt PyQt4 pyrad pyramid PySide Python Python 2.5 python 2.7 python 3 python c api python speed python-mssql python3 pywinauto Qt Qt4 queue rabbitmq radius raw sql re redis redsolution redsolution cms regexp regular expressions release repoze.bfg RequestContext reusable apps robokassa rss ru ruby ruby-on-rails sample satchmo scalability SciPy scraping screencast search selenium self.error seo server setattr settings setuptools shell sikuli sms snippet socket.io software sorting south sphinx spider sql sqlalchemy sqlite ssh startup step-by-step subdomain subversion svn SyntaxHighlighter system tags tdd tddspry teh drama template templates templatetags test testing thinkpad threading threads tips tips and tricks tools tornadio tornado tornado server tricks tutorial tweepy twisted twitter typography uapycon Ubuntu ucsvlog uml Uncategorized unicode unit test unit testing UnitTest Unladen Swallow upload urllib urls utf-8 uwsgi validation vcs versioning video vim virtualenv Visual Studio vkontakte voip wave web web-devel web-services web-разработка webdev webfaction webkit webpy websockets webtest widget widgets Win API windows Wirbel work wrapper wsgi wxPython wxWidgets wysiwyg xapian xml xmonad xmpp xpath yandex youtube zip zomg zope [cdata[cbv]] [cdata[ci]] [cdata[class based views]] [cdata[continuous integration]] [cdata[django framework]] [cdata[django-sphinx]] [cdata[django]] [cdata[nginx]] [cdata[python]] [cdata[virtualenv]] [cdata[программирование]] автоматизация администрирование администрирование django админка алгоритмы архитектура атрибуты базы данных Без рубрики безопасность библиотеки блоге бот веб-разработка видео Визуализация данных вконтакте Все записи гвидо ван россум граббер графика графы декоратор декораторы дескриптор дескрипторы документация заметки игра жизнь идея интересное киев Клиентам книги конференция личное математика метаклассы модели модули монады морфология мысли невозможное новости о облачные вычисления обо мне Обработка данных оптимизация оптимизация кода Основная лента основы парсинг парсинг сайтов перевод песочница Питон поебень поиск правила кодирования программирование Проектирование производительность работа рабочее размышлизмы Разное разработка разработка приложений разработки регулярные выражения сайт событие события ссылки статьи тестирование тесты Тюмень убунтариум фигня философия формы форум Хабрахабр хакинг хостинг шаблоны шаблоны проектирования эксперимент Эксперименты юмор я пиарюсь Яндекс