metaclass | Гуе-визардо-мышедизайнерская разработка софта

Гуе-визардо-мышедизайнерская разработка софта

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

Threaded | Top-Level Comments Only

Серьёзно. Но это, похоже, в рамках одной конторы.

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

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

Именно поэтому дельфи до сих пор используется и будет использоваться. Потому что они сделали нормальный визуальный интерфейс. А разные там программсты предпочитают текст, и делают визуальные редакторы на отьебись.

>> А что ты используешь для представления базы в виде текста?

Вообще-то база изначально в виде текста и существует, исходник так сказать.
Можно поставить вопрос иначе - а что используется для преобразования исходного текста в какую-нибудь визуализацию?

База существует в виде понятных ей одной бинарных файлов. Ну, и часто - в виде diff-скриптов в source control-е, которые если последовательно запустить - получится такая же база. Где ты там исходник видел?

mplayer с libaa? :)

У меня два разных исходника: для создания с нуля и для миграции между разными версиями.
В конечном итоге - diff-скрипты и есть исходник.

\\А вот хуй - в трёх местах меняются, в одном остаётся старая.

Ага, а потом продвинутые (как тут недавно) на паттерны ругаются.
Вот закладыватся можно на то, как это сделано... с паттернами или без.

\\И тогда все это будет нормально растягиваться как надо.

Сразу видно что человек гуишку не программровал.
Нормально, это как? ;)

Мне в голову приходит только рейс кондишн какой-нибудь,
когда один поток берёт из All, второй из каких-нибудь
фиксированных ебеней, и один за другим не успевает.
Может, и другие варианты есть, но придумать не могу пока.

не... правда банальнее, и жоще

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

//Сразу видно что человек гуишку не программровал.

Сразу видно что человек других не слушает, считает себя умнее всех, и свое мнение объяснить не может.

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

Что бы эти бинарные файлы создать требуется дать серверу команды.
Либо эти команды даются в текстовом виде скриптом и это и есть исходник
либо это делается через ГУЙ.

Если у какого-то сервера есть возможность создать объекты в базе только через гуй и мышку - это адов пиздец и втопку такой сервер.

Некоторые сервера даже бэкапы баз делают в текстовый вид.

Кстати, про бинарный вид. Программы они тоже работают только в бинарном виде (условно, не будем вдаваться в различные варианты :) ) Тем не менее, исходником программы называют не этот бинарный вид а ее текст на котором она была написана, на каком-то из языков программирования, в текстовом виде.

Речь о том, что исходники базы обычно являются последовательностью SQL-команд, которые меняют схему от начала существования базы. Читать это чтобы понять текущую схему базы никто в здравом уме не будет.

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

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

А как ты эти исходники синхронизируешь?

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

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

Не разъезжаются.
Создавать таблицы в стиле "добавил 10 полей, удалил 5, добавил еще 20" меня огорчает, поэтому я для новых деплойментов создаю базу из финальных скриптов.
Я в голове не смогу удержать разработку, если таблица будет разбросана по нескольким файлам.

>> Речь о том, что исходники базы обычно являются последовательностью SQL-команд, которые меняют схему от
>> начала существования базы. Читать это чтобы понять текущую схему базы никто в здравом уме не будет.

Как по мне - скрипты для перевода базы из старого состояния в новое - это не есть исходник базы.
Исходник - это один скрипт прогнав который получаем базу требуемой структуры.
Другое дело что когда в базе есть какие-то данные (а это практически всегда) то исходника обычно не достаточно и требуются специально написанные скрипты по изменению базы с данными. Они тоже нужны и хранятся в CVS но исходником не являются, это уже типа инструмент.

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

Речь идет только о схеме данных. Всякие хранимки и вьюшки - это тот же код, их надо хранить также как остальные исходники.

Да, так удобно.
SQL-файлики хранятся в контроле версий и именуются YYYYMMDD_Description, в каждом - создание табличек, раздача полномочий, создание процедур и т.п.
В каждом последующем может быть добавление полей, изменение процедур и т.д.
При установке смотришь, какие скрипты ещё не наложены и запускаешь последовательно.
Тогда у каждого клиента будет версия базы, соответствующая определённой версии софтины.
Хуёво только, что у MS нету стандартного механизма для таких вещей, всё приходится руками делать, пихать в setup и прочая.
После выхода 2010 студии на форумах смеялись ещё. Мол, да, подключение к базе, схема - всё есть. А как на практике быть? Ни тебе развёртывания автоматического, ни диффов. Кто же в жизни из студии к продакшену подключается? В таком духе.

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

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

Вообще говоря, я и скрипты-исходники делаю крайне редко, только когда они нужны именно в виде скрипта что бы сделать по нему diff и посмотреть разницу. А обычно я работаю с последней версией в виде копии рабочей базы, хожу в нее через IBExpert который показывает мне объекты базы в виде дерева и дает массу удобных плюшек. Однако, для внесения изменений в структуру базы я использую только SQL-текст в том же эксперте и не юзаю его множественных ГУЙ-оглупляторов которые подменяют исходник некими гуевыми примочками которые не всегда понятно как связаны с реальными SQL-командами.
Крайне редко я пользуюсь этими оглупляторами когда они делают то что мне понятно, но лишь для того что бы посмотреть какой SQL в результате генерится, и в дальнейшем обычно использую именно его.

Но к примеру если надо посмотреть DDL таблицы - то я смотрю ее именно на вкладке с ее SQL-текстом а не там где оно же представлено в более графическом виде, ибо мне так быстрее и понятнее.

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

Threaded | Top-Level Comments Only

Page 2 of 3

Гуе-визардо-мышедизайнерская разработка софта

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject

no subject