Один оператор — одна транзакция, как хорошо. Транзакция — дело темное, изучить ее невозможно, а предвидеть ваще нельзя. Вот напишет оракл новую версию, вот достанет тестовые скрипты от 1975 — вот и оттестировали во всех режимах. Как оно работает — никто не знает.
Мы люди простые, у нас вечером база копируется в «заднюю», а на задней жужжит аналитика без транзакций и изменения базы. Дешево и сердито.
Увлечение трех-этажными конструкциями oracle, равно как и увлечение oracle формами имеет разумные пределы. Чаще просто пишем на plsql простой if и все. Если конструкция слишком сложна — от нее следует отказаться вовсе.
Мобильные настолько тихие, что их на улице ваще не слышно, а зимой и вибро не почувствовать. Поэтому рингтон нужно ставить самый громко-противный, чтобы не пропустить звонок. Раньше были мобильники с хорошим звуком, а у смартов не звонок а издевательство. А переключать рингтон входя и выходя — это ваще не для людей. Статья для марсиан.
Разумеется, и каждая команда хороша для своего проекта, поэтому лучше набирать команду ежемесячно. Да вот беда, уж очень трудно сразу узнать хороший ли специалист. Вот есть команда со своими умонастроениями, другие бы за другие деньги на другом проекте сделали бы во сто крат лучше.
Тысяче-первая статья о второстепенных проблемах, которые мало кого волнуют. Теоретики потому теоретизируют, что практически ничего не пишут. Основная проблема — как сделать вот этот кусок программы не зависимым вот от этого куска программы. Допустим два куска имеют разные интерфейсы — за день можно настрочить огромную формальную обертку одного в другое. Ну и что, что избыточный и глупый код — зато он делается на раз. А давайте программировать сверху вниз, по плану, по порядку. А на деле всегда снизу вверх — уж что получится в полном беспорядке. Каждое наследование — это порождение новой сучности. Вот возьмем например клиента и товар — как хорошо, как любят такие примеры. А вот другой пример: абракадабра12 наследуется от нонсенса16, который наследуется от абстракция_палата_6. Всего то одна тысяча сучностей, нетрудно запомнить, все логично и последовательно. Порой лучше написать повторяющийся код только для того, чтобы класс не зависел от других классов. Вместо наследования влепить интерфейс и сделать отдельно. Ах как это не логично, ах как это избыточно, ах на диск не поместится.
Это еще что, вот представьте, что на каждой точке у вас оригинальная софтинка, которая была написана несколько лет назад, а абгрейдить ее к общему знаменателю не моги без дополнительной оплаты с клиента, а сопровождать обязан по части исправления мелких ошибок. А обороты больше чем в суппермаркете, и работают точки круглосуточно.
Здесь излагается как написать программу. А вот этого как раз никогда и не требуется. Требуется нечто иное. Надергать разных библиотек, всяких там баз данных и собрать из них то, что нужно. Или напротив, написать движок для игрушек, банков, бухгалтерий. А этот движок кому то понравится? Ну, сперва написать простенький. Или на движке нарисовать свою дизайнерскую реализацию. А в процессе выяснится, что использованные средства никуда не годятся, и их нужно поменять на подходящие. Результат таков: нам удалось на платформе такой-то добиться вот такой крутизны. Если я рисую квадратики на экране, то я никогда не использую эти квадратики, а если я использую эти квадратики, то я их всяко не рисую, и не умею. Если я домо-строитель, то я уж никак не машино-строитель.
Да, хорошо иметь банк данных, где будет и то, и это, и еще вон то. Да вот беда, кто бы не вводил эти данные, непременно сделает ошибку, да мало того, еще и специально напортит. Конечно, как ведь хорошо расположить базу деревом, вон файловая система и есть дерево — чем не база? В файловой системе есть еще и ссылки. Задание ответственному работнику: пойди ка, милай, проверь дерево базы данных со ссылками много ко многим на предмет соответствия реальному положению дел. Зачем нужна база данных, где сущности ветвятся себе как джунгли и только гуру-сталкер знает что где лежит, правда он уже пять лет на пенсии? Реляционные базы живы потому, что живой человек может контролировать данные в таблицах, и только в таблицах, и ни в чем, кроме таблиц — фамилия-адрес, фамилия-адрес. А всякие там ораклы путем весьма запутанных противоречивых алгоритмов пытаются такую уродливую форму хранения данных как то там обработать. Считается что конечному пользователю все должно быть просто и понятно, а программист пусть выкручивается как хочет — его проблемы ваще никого не волнуют. В базе все по прежнему — достоверность данных важнее всех остальных свойств вместе взятых.
Вы так интересно пишете, что кто то де будет читать мою программу? Может и будет конечно, но обычно не правильный класс просто выбрасывается и на его место пишется новый с теми же public. Все, что за рамками public просто никого не интересует. Все красивости только в интерфейсе. Внутри разбираться некому, некогда и не зачем. Может кто то и посмотрит в качестве примера при переписывании. У каждого свое видение и логики и красивости. Это где такое интересное место, чтобы кому то смотреть внутрь кривого класса?
Вот есть у меня такой кодогенератор, который из файла txt формирует файл obj. Я потому правлю obj и другим кодогенератором делаю exe. Да, исправленный obj будет затерт следующей кодогенерацией из txt. Кодогенератор в вашем понимании, это недо-транслятор с недо-языка с недо-компиляцией. И зачем нам недо-средства? Вот MS придумала MFC и обделалась, а Дельфи придумала VCL и преуспела, тогда MS придумала c# усердно и методично скопировав VCL, но снова обделалась с DataSet, но решила преуспеть с WPF. Кодогенератор — это квадратура круга, на ограниченных задачах работает, но писать на нем серьезные проги не рекомендуется.
Вот никак в толк не возьму, если у вас есть некие метаданные для некоего кодогенератора, то чего бы сразу и не написать прогу, которая по этим данным и работает без всякой кодогенерации? Медленно? Так медленно только на очень ограниченном куске программы — его отдельно написать. Лежат себе в базе данные, а прога их читает и отрабатывает. Кодогенераторы иногда используются чтобы сбросить структуру данных в исходник программы и предоставить программисту готовые переменные с названиями по этим данным. Все это глючит всегда и у всех и используется только в одну сторону — любое изменение в программе и прощай кодогенерация. Правильные пацаны кодогенераторов не используют.
1002 рекламная статья — какие у нас продвинутые кадры работают. Да какой коллектив слаженный, да каким методы программирования продвинутые. Ну просто ой.
Экий вы право же продвинутый. Я сознательно написал «переменная», что вообще говоря в терминах шарпа совсем никак. А потом долго описывал какие то ипостаси, которые так же никак, и связывал объект с типом внешним и внутренним на этапе выполнения, хотя нет ни внешних, ни внутренних типов. И писал про дырявые представления — т.е. изначально неверные представления. Чисто для понимания, а вовсе не для документирования. А вы, как я полагаю, решили блеснуть глубиной знаний шарпа, не так ли?
Писать совершенные, взвешенные и продуманные суждения означает не писать ничего и никогда. Так устроен этот мир.
Атрибут принадлежит типу, и если типы различаются списком атрибутов — значит они различны. Здесь кроется большая опасность, так как нужно думать когда атрибут выполняется — он ведь исполняемый класс в отличие от типа. Полагаю что шарповцы не смогли исключить все ошибки и далее не смогут.
Мы люди простые, у нас вечером база копируется в «заднюю», а на задней жужжит аналитика без транзакций и изменения базы. Дешево и сердито.
Это я здесь играю.
99% — игры
0.9% — одноклассники
0.09% — бухгалтерия
0.01% — технологические процессы
Атрибут принадлежит типу, и если типы различаются списком атрибутов — значит они различны. Здесь кроется большая опасность, так как нужно думать когда атрибут выполняется — он ведь исполняемый класс в отличие от типа. Полагаю что шарповцы не смогли исключить все ошибки и далее не смогут.