Python-сообщество

И лучше было бы создать отдельную тему.

Daevaorn
Так автоматизируйте. Что мешает?

Это отдельная большая(лишняя) работа и не понятно как это автоматизировать.

Daevaorn
Модель первична.

Понятно, но какая Объектная(Models.py) или Логическая(ER)
От чего плясать, от диаграммы к питону или от питона к диаграмме?

Daevaorn
Куда уж визуальнее и функциональнее чем имеющийся DSL?

а это что такое, Domain-Specific Language для шаблонов генерации HTML, или что-то иное?

Согласен, перенести бы часть ветки в отдельную тему, начиная от моего первого поста.

PyCraft
Это отдельная большая(лишняя) работа и не понятно как это автоматизировать.

Но, если очень нужно, то некую рутину всегда можно сократить.

PyCraft
Понятно, но какая Объектная(Models.py) или Логическая(ER)

Models.py

PyCraft
От чего плясать, от диаграммы к питону или от питона к диаграмме?

От питона к питону. Зачем плодить сущности, если питон сам очень хорошо для прототипирования и само-документирования?

PyCraft
Domain-Specific Language

Именно. Само описание джанго модели максимально визуально и функционально.

Отредактировано (Июнь 10, 2008 19:19:23)

Ничего не имею против Python и Django ибо первый нравится, а второй люди делали для себя, а не для меня. Однако, не разделяю Вашего оптимизма по поводу их идеальности для моделирования данных. Они для этого совсем не предназначены. Для этого существуют специальные средства (IDEF,UML) Графические примитивы всяко нагляднее и проще, чем модели в Django. По крайней мере для меня, а я именно для себя ищу инструмент. Если бы в Django был такой визуальный инструмент, напрямую работающий с кодом модели Django(а не с моделью базы данных) то это было бы намного удобнее чем городить описанную выше цепочку. Технически это совсем не сложно реализовать даже студенту(намного намного проще, чем то что понаделано), поэтому я и удивился почему его нет в базовой версии. Просто не нужен был, задачи БД были простые, не досмотрели. Нужное подчеркнуть

PyCraft
Вашего оптимизма по поводу их идеальности для моделирования данных. Они для этого совсем не предназначены. Для этого существуют специальные средства (IDEF,UML)

Django это Agile в чистом виде. И лишние артефакты ему не нужны.
Идея, короткое совещание в команде и реализация. Что-то не так, быстрое изменение и опять проверка результатов.
Никаких больших подготовительных этапов. То что вы предлагаете, это overenginiring в чистом виде, применительно к проекту на Django.

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

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

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

Разработчики Django не являются разработчиками языков программирования (о чем они декларируют сразу), также они не разработчики, к счастью, всяких сомнительно полезных гуевых приблуд. Уж лучше пусть они время тратят на дело.
DSL представление джанги максимально визуально и практично.

PyCraft
Просто не нужен был, задачи БД были простые, не досмотрели. Нужное подчеркнуть

Работая с Django, вы о БД должны думать в последнюю очередь. Ваша задача - придумать модель данных и реализовать её в виде классов. Какой бекэнд хранения у них, это уже вторично. Может быть это вообще не реляционная БД? Вы же всё хотите перевернуть с ног на голову.

Daevaorn
Работая с Django, вы о БД должны думать в последнюю очередь. Ваша задача - придумать модель данных и реализовать её в виде классов. Какой бекэнд хранения у них, это уже вторично. Может быть это вообще не реляционная БД? Вы же всё хотите перевернуть с ног на голову.

Интересно, ка Вы предлагаете “придумать модель данных”(или упаси боже “Знаний”), когда количество сущностей начинает превышать 7, я уж не говорю про 70, когда удержать всю модель в голове, со всеми ее связями и ограничениями целостности, и тем более воспринять ее визуально из кода становится проблематично и не важно какой это код Django или SQL. С последним даже проще будет, т.к. не нужно в уме преобразоввывать типы полей Django к типам SQL, но даже он не годится. Django отличный инструмет для создания сайтов или даже многозвенных приложений, но не моделирования данных. Модели там предназначены для упрощения программного доступа и управления данными, а не для концептуального, информационного или логического моделирования, и тем более не для визуального представления.
Врядли стоит отказываться от фундаментальных концепций моделирования данных в пользу прикладного инструмента который по словам самих авторов не имел никакой фундаментальной базы, а был разработан чисто из практических соображений с единственной целью - упростить и ускорить их работу. Они с этим справились отлично, так что хвала им и Джанге, но без фанатизма.

PyCraft
когда количество сущностей начинает превышать 7, я уж не говорю про 70

Тогда вы ошиблись с выбором Django, как инструмента.

PyCraft
Django отличный инструмет для создания сайтов или даже многозвенных приложений, но не моделирования данных.

Безусловно, в том моделировании, в котором нуждается проект на джанго, он (DSL) справляется.

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

Вторая часть тезиса противоречит первой. За счет отсутствия необходимости долгого моделирования и проектирования, достигается упрощение и ускорение.

Daevaorn
Вторая часть тезиса противоречит первой. За счет отсутствия необходимости долгого моделирования и проектирования, достигается упрощение и ускорение.

Противоречия нет, есть Ваша трактовка. Моя трактовка в том, что упрощение и ускорение достигается за счет отказа от моделирования, а не за счет его ненужности. Просто так быстрее выполнить заказ, показать товар лицом и получить вознаграждение. Более того, когда в скором времени вскроется отсутствие чего-то или функциональность окажется не такой какая ожидалась, это на руку разработчику, всегда можно ткнуть заказчика мордой в ТЗ и попросить еще денег на доработку. Выгодно? Несомненно. Юридически грамотно? Бесспорно. Но плохо пахнет и не для всех подходит.

Для цели побыстрее заработать денег, лучше не придумаешь.
Ремесло, одним словом. При таком подходе, ни о каких высоких технологиях и науке речи быть не может.
Только “штучки” и “прибамбасы”, которые можно быстро обсудить и изготовить. Типа “отправь SMS сообщение на номер 999 и выиграй миллион”.
Лично я пытаюсь применить Django по его назначению, но в рамках фундаментального проекта и мне без моделирования не обойтись.
Если без моделирования и глубокого продумывания, то потом переделывать самому боком выйдет.

Daevaorn
Тогда вы ошиблись с выбором Django, как инструмента.

Неужели только < 7 и только плоские таблицы без оптимизации? Может это Вы ошиблись?

Отредактировано (Июнь 11, 2008 12:53:17)

PyCraft
Противоречия нет, есть Ваша трактовка. Моя трактовка в том, что упрощение и ускорение достигается за счет отказа от моделирования, а не за счет его ненужности. Просто так быстрее выполнить заказ, показать товар лицом и получить вознаграждение. Более того, когда в скором времени вскроется отсутствие чего-то или функциональность окажется не такой какая ожидалась, это на руку разработчику, всегда можно ткнуть заказчика мордой в ТЗ и попросить еще денег на доработку. Выгодно? Несомненно. Юридически грамотно? Бесспорно. Но плохо пахнет и не для всех подходит.

Для цели побыстрее заработать денег, лучше не придумаешь.
Ремесло, одним словом. При таком подходе, ни о каких высоких технологиях и науке речи быть не может.
Только “штучки” и “прибамбасы”, которые можно быстро обсудить и изготовить. Типа “отправь SMS сообщение на номер 999 и выиграй миллион”.
Лично я пытаюсь применить Django по его назначению, но в рамках фундаментального проекта и мне без моделирования не обойтись.

Что-то это вас совсем унесло не в ту степь. Разглагольстовать все умеют. Только в на веб-морду их не повесишь и сервис клиентам не предоставишь.

PyCraft
Если без моделирования и глубокого продумывания, то потом переделывать самому боком выйдет.

Если вам платят за глубокое продумывание, то пожалуйста. Просто, имея такой инструмент как Django, дешевле сделать, ошибиться и поправить, чем глубоко продумывать, плодя артефакты в виде UML (боже упаси) и прочие.

PyCraft
Неужели только < 7 и только плоские таблицы без оптимизации? Может это Вы ошиблись?

7 это мало. Даже 30 нормально и 35. Но 70 уже перебор и ошибка в выборе.

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

9и ступенчатого монстра я придумал без долгого обдумывания непосредственно во время чтения этого форума.
Долго моделировать мне не то, чтобы нравится. Модель это теория, а построение теории это основное занятие научных работников.
Вот именно за глубокое продумывание технических деталей мне не платят, а жаль.
UML мне тоже не нравится, просто это стандарт, принятый во всем мире. С моей точки зрения, в UML есть фундаментальные ошибки которые являются следствием менталитета его авторов сложившегося под влиянием различных DSL. У меня свой типа “UML” и он в основном не графический, но ложится на интерфейс замечательно.
Что касается моделирования баз данных, то я предпочитаю не UML, а IDEF0, который по сути является DSL для описания схемы базы данных. Надеюсь аббревиатуру DSL вы не ассоциируете исключительно только с Django.