Вот где проявился JIT

Вот код, который пришлось быстро втыкать дабы отвязать приложение от NHibernate, не убирая его из референсов и компиляции:

        protected virtual void doStartUp() {
             var dir = AppDomain.CurrentDomain.BaseDirectory;
             if (File.Exists(dir + "\\NHibernate.dll")) {
                 var sfp = Container.get<ISessionFactoryProvider>();
                 if (sfp != null) sfp.Get(null);
             }
        }

В таком виде - не работает

А вот в таком:

        protected virtual void doStartUp() {
             var dir = AppDomain.CurrentDomain.BaseDirectory;
             if (File.Exists(dir + "\\NHibernate.dll")) {
                 prepareSession();
             }
        }
 
        private void prepareSession() {
            var sfp = Container.get<ISessionFactoryProvider>();
            if (sfp != null) sfp.Get(null);
        }
Уже замечательно...

Экзамен по БД №1

? @makedefault - ? - вернул на посмотреть - правильно описал что делает проца, вопрос про NULL ставит в тупик
1. схемы
zetam - вызов комманд для - инсталлятор базы - 4
zeta - !неправильно сказал где живут интерфейсы! , вьюхи, интерфейс базы - 3- (потом)
zetan - псевдонимы, используется во вьюхах - 3
zetai - приватные члены - 3
zetah - история таблиц? - 2

2.
entity
code-, name+-, comment+, idx+, version+, usr+, tag+, uid- 4
zentity
marks-, groups-, outercode+, startdate?, enddate?, shortname+, fullname+, active+, sid- 3

3. history 2

4. name+, addvviewfields+, interface?, baseinterface?, makehist+, makepkg-?, makedefault+

5. Таблицы более менее на 4-

Итоговая оценка - 3-
Некоторое понимание того с чем работал - на 4, все остальное как в тумане.

Bugzilla

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

Шаблоны новых ошибок
Прочее

• Несовместимость с браузером (не с Mozilla) 

Касяки 2011-01-31

1. (SVN)Разрешение конфликтов папок SVN - надо было удалить скрытую папку .svn там где был конфликт, потом туда же CheckOut, а не грохать все.
2. (SVN)В коммитах не забывать про *.csproj - они хранят настройки проекта, это обязательно к расшарке
3. (SVN)Переимнование папки в каталоге не приводит автоматически к перименованию папки SVN, требуется именно выполнить комманду SVN->rename и потом коммитить либо пользовать VisualSVN
4. (SVN)Перед коммитом или переименованием папки надо обязательно  делать апдейт
5. (NET)Обязательно изучить пространство имен System.Collections.Generic, понимать вообще генерики в частности нотацию IDictionary
6. (C#) Не забывать потенциальный конфликт имен классов и пространств имен, например как с Console, не допускать. 
7. (С#,NET) Надо освоиться с Dictionary - много времени ушло на простейший foreach 
8. (Бардак) Правка замены регулярных выражений, надо убрать краевые скобки, после дебага и иего завала вдруг приходит вопрос такой, а что тут неправильно? value = value.Replace(@"^""([\S\s]*)""$","");, теперь билдится, но не работает, естественно если почемуто Regex.Replace заменяется на string.Replace - нечему валиться, ну и понятно, что когда нужно убирать кавычки, а код затирает все - это обречено на провал
9. (regex) Неправильная конструкция [--]  - непонимание конструкции
10. (Бардак) Для регексов .net использовалась неподходящая туловина для дебага
11. (Бардак) При столкновении с проблемой в регексе не было желание системно подумать в чем проблема и переписать регекс с ноля, начались напластования "вариантов" кода.
12. (Бардак) Повторяется нежелание понять суть и стопорение на синтаксисе или не знании конкретного метода:
1. при формировании расширения применения свойств: непонимание того что есть псевдокод, использование первого попавшегося и абсолютно неподходящего метода выпавшего в интеллисенсе, отсуствие как и с транзакциями заготовки оболочки общей логики метода
2. так и не дописана была сигнатура №2 - отложена как "сама собой и просто" и недописанная
3. задача про документирование и тестирование DictionaryExtensions - после 20 минут и задачи "разобраться что к сему в коде и убрать лишние методы" вопрос "почему столько оберток одного и того-же", хотя было сказано почему "не было параметров по умолчанию" и "одного и того же" оказалось так и покрыто мраком, то есть понимания работы класса как не было так и нет.

Резюме

1. При цейтноте низкая устойчивость к стрессу - 2 реакции - ступор без кодинга "попытка думать" при этом код не пишется вообще никакой это когда задача с ноля, 2-я - буздумные правки кода, изменения тестов, использование чего попало из подсветки и автоподстановки в полуработающем коде.
2. Отсутствие системного видения задачи, увлеченность собственно кодированием, не зависимо от сложности задачи, снижение общей дисциплины - теряются требования, неправильный порядок действий, отсутствие самоконтроля тестами.
3. Очень низкий уровень алгоритмического видения, неумение пользоваться на бумажке типовыми вещами типа блок схем, деревьев решений или зависимости требований, как следствие аномальный порядок выполнения, сцепление условий. Что еще множится и трояется в сочетании с 1 и 2 пунктами.
4. Позитив: больше глядится в подсказки, чуть легче читается код, более быстрое формиование типовых конструкций, более частый и грамотный цикл коммит-апдейт.

Рекомендации

Общая:

Высока вероятность проф. непригодности для выполнения задач системного и невизуального прикладного программирования. Отсутствие опыта абстрактного анализа и программирования без моментального визуального эффекта. На данный момент НЕ компенсируется уже знанием синтаксиса языка и общими классами, конструкциями .NET. Ибо проблема в самом умственном подходе и общих навыках, на данный момент профиль конечно больше про веб-мастеринг и визуализацию, где внешний эффект важнее средств достижения и примитивен по алгоритмам (как только это усложняется появляется код например а-ля обхода инлекса файлов с очумелой логикой, а это javascript+DOM, то есть все знакомо).

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

Исполнителю:

1. Обязательно перечитать этот блог, замечания в SVN
2. Просмотреть весь итоговый написанный им совместно с старшим программистом код, вспомнить как же формировались решения.
3. Изучить по документации все синтаксические конструкции и структуры использованных в коде классов
4. Не постесняться и не полениться записать вопросы и "не могу вспомнить почему..." возникшие при чтении замечаний и кода - это точно те вещи в которые потом снова будет "вляп"
5. Найти время по верхам пробежаться по основной библиотеке классов .NET, по основным пространствам имен, чтобы иметь представление о том, какие собственно направления охвачены уже базовыми классами
6. Придумать себе ритуал или четкую инструкцию на случай вподания в ступор или хаотичное кодирование. Главное научиться ловить себя на этом и четко вставать на паузу, думать что делать. 
1. Как замечать эти состояния:
1. при наличии четкой задачи и требований в течение 5 минут не написано ни одной буквы
2. документация читается и из нее НИЧЕГО не оседает в голову, поиск ведется по случайно выбранным из контекста словам, а не по полному описанию задачи
3. при неработающих тестах идет уже третья правка кода в одном месте БЕЗ анализа причин сбоя и без динамики в выполнении тестов
4. заминка с тем что "не знаю какой тут надо класс использовать" а при этом полное отсутствие канвы где же его думается поиспользовать
2. Что нужно предпринять (рекомендации расписаны именно исходя из дефекта в алгоритмике и замыкательстве на коде)
1. Если ступор - пробежать глазами требования и понять - может в них все же есть простые требования которые можно уже выполнить и забыть, также требования могут содержать подсказки
2. Если заминка вызвана незнанием класса заставить себя написать псевдокод с псевдовызовами, чтобы потом уже подставить правильные имена, но чтобы канва получилась
3. Если нет общей канвы, отвлечься от кода, переменных и попробовать на бумаге разрисовать алгоритм работы процедуры на более высоком уровне, а потом писать код
4. Если в голове хаос и ступор знать, что старший программист не поможет, и понять что ПСЕВДОКОД который дает выход на РЕАЛЬНЫЕ ВОПРОСЫ к старшему В ЛЮБОМ СЛУЧАЕ МОЖНО ЛЕГКО НАПИСАТЬ ПРОСТО В ПРАВИЛЬНОМ ПОРЯДКЕ СОБИРАЯ ТРЕБОВАНИЯ В АЛГОРИТМ.
5. Часто ступор над уже каким-то но не рабочим кодом ознгачает, что лучше код полностью стереть чтобы не мешал и писать с ноля но не в лоб, а через блок схему и псевдокод.
7. Что точно делать нельзя:
1. Задавать вопросов отражающих полное непонимание задачи или халявное к ней отношение - конкретный вопрос бывает только про конкретный неизвестный класс или конструкцию кода или про работу неких внешних задействованных систем, все остальное - это признак лени, ступора и нежелания отвлечься от самого кодирования и подумать над смыслом задачи самому, плюс такие вопросы тупо отвлекают и злят.
2. Менять тесты (кроме случаев явных багов в тестах)
3. Нарушать общий порядок работы - файлы, набор классов - комит - сигнатуры вызовов, интерфейс - коммит, тесты - коммит, далее цикл - (чота изменил - тесты по другому - коммит) иначе пропускается значимый шаг и в итоге задание невыполнено.
4. позволять себе что то использовать и не понимать что это, использовал Console.WriteLine("") - будь добр посмотреть все методы-свойства Console, поиспользовал IDictionary<string,string> будь добр и IDictionary изучить и что такое генерики "<>" и т.д.

Comdiv.Core 3 - пересмотр конверсаций

Конверсации версии 2 оказались неуместными.
Во первых сами длительные транзакции оказались опасными и невостребованными.
Архитектура транзакций и обработки событий конверсаций, их менеджмент и хранение были крайне усложнены. Львиную долю цикла делал ужасный BaseApplication, а сессии все равно жили своей жизнью.

В версии 3 решено полностью пересмотреть подход.

1. Сессии пусть живут отдельно
2. Никаких постоянных транзакций, только Flush.Never и соглашение, что обновление данных в защищенном контексте
3. Нет как таковых конверсаций
4. Вместо этого переписан шаблон приложения в Core, WebApplicationBase, от него все наследуется.
5. WebApplicationBase инициирует IApplicationLifecycleManager из ioc и ему делегирует события веб - тут если надо можно завесить обработчиков рекветов. Это заместо перехватчиков конверсаций.
6. Конверсации вообще удаляются из проекта

New metadata and OOP features in MacroTSQL

New feature 1.

Normal reflection over XML attributes (work on every object type whick keeps it's source code in sys.sql_modules (all except tables)

Assume that such view was created:

/*@
<myvar val1="1">2</myvar>
@*/
create view myview as select 1 as id

Now you can use comdiv.schemaview to find and test it:


select
type,
fullname,
comdiv.getattribute(sql,'myvar'),
comdiv.getsubattribute(sql,'myvar','val1')
from
comdiv.schemaview
where
comdiv.hasattribute(sql,'myvar')=1

So result will be :
type fullname col1 col2
---------------------------------------------------
VIEW dbo.myview 2 1


comdiv.schemaview
works for now above SP,F,T,V, not for tables.
Supports visualization of
name, module->name, module->class, module->method attributes,
events and some others
sygnal about 'isinterface','isprivate' due to applyed schema

For MacroSQL created object additionaly SourceSQL column provided
which contains pure sql (no declaration) of code before prepocessing

comdiv.validateschema
is FxCOP-like stored procedure that analyzes schema through comdiv.schemaview and search for errors, mistakes and not well formed metadata.

For example - after such view was created, i see:
exec comdiv.validateschema
=type====|===name====|=severity=|=errorcode=|info
=VIEW-----|-dbo.myview--|---40-----|--40-------|-module is not defined
=VIEW-----|-dbo.myview--|----5-----|--60-------|-best practice is to define class and method of object =

/*@
<myvar val1="1"></myvar>
<module name='mytestmodule' class='stub' method='sampleview' />
@*/
create view myview as select 1 as id

will match requirements


New feature 2.

Object-like style of calling inside MTSQL-style procedures.

Given such procedure (named due to some schema needs or historically):

/*@
<module class="utils" method="printdate" />
@*/
create proc dbo._SP_print_date as begin
declare @now datetime set @now = getdate()
print @now
end
in M-TSQL procdures you can call it not by real name, but by 'class'
NOTES: class names are applyed only if they are already exists!!!

/*@
<name>testproc&lt/name>
@*/
create proc _ as begin
exec utils.printdate
end
Code is very readable and is good for migration
You need just keep class->method names, but safely rename real object (with following recompilation of MTSQL code)

MTSQL : Strange '_'-named objects, why?

PROBLEMATIC
Almost all procedures, functions and other programmatical stuff in Macro T-SQL core and descendant scripts are  implemented in following mode:

/*@

<name>myprocname</name>

this is my real proc...

@*/ 

create proc _ as begin
         -- some stuff
         return
end



Why we use such strange syntax except usual :

create proc procname as begin
/* this is my real proc... */
         -- some stuff
         return
end

QUESTION ONE: WHAT'S FOR?

ANSWER : "CREATE OR REPLACE" AND NAME AMBIGUITY
T-SQL not have CREATE OR REPLACE constructions in it. So real-world scripts are looks like:

if object_id('procname') is not null drop proc procname
go 
create proc procname as begin
         -- some stuff
         return
end

Where are some visible problems in such code:

1. name is repeated 3 times - so it's not good when you copy paste it or correct names, and it's anti-pattern
2. you MUST execute this code in 2 commands - it is not big problem in SQLWB, but when you work from program client you must keep it in mind and perform 'GO' parsing and batching code

But in MacroSQL-style definition we have problems solved:

1. no ambiguity - name defined at one place
2. one command execution - cleaning up of objects performed by MTSQL DDL Trigger which drops object and then recreate it by provided SQL ('_' object dropped TOO, so you ALWAYS can create it

QUESTION TWO : WHY DDL TRIGGER NOT PERFORM IT'S STUFF WITHOUT SPECIAL-NAME USING?

ANSWER ONE: IT CANNOT
Usual (not AFTER) DDL triggers are executed not AFTER  COMMIT of creation, but AFTER CREATION ITSELF, so object MUST BE CREATED. If we try to call create proc procname, we still will caught error if such object exists even if we use DDL trigger for CREATE_PROCEDURE. (no analog of 'INSTEAD OF' ralized for DDL triggers).

SO WE NEED TO PROVIDE SPECIAL NAME WHICH NEVER BE REALLY EXISTED AFTER PROCESSING.

We decide to use '_' style - it's realy mimimalistic object name, and we havn't see real databases with object called 'dbo._' 

As alternative we choose it from another syntax:


create proc procname_mtsq as begin
         -- some stuff
         return
end
Trigger must have response to _mtsql suffix and drop it with creation of normally named object. But it's very bad:

1. less readable  - no visible difference with usual definitions
2. less ecological - we not have reserved just unusable '_' name, but whole NAMING RULE

ANSWER TWO: ECOLOGY OF PROJECT
MacroTSQL Trigger and Preprocessors that it calls, may be broken for usual syntax, they awaits some attributes (not provided by usual code), they perform some large operations on source code.
If such trigger will work on everything that occures in given DB, it will be dangerous for usual schemas and usual scripting.
By '_' name we have expressive and easy to use 'keyword' which differentiate Macro TSQL-awared object creation scripts from usual. MTSQL works only with it's stuff, not on usual procedures. 

QUESTION 3. What to do if my database have object named 'dbo._'?
Answer 1.: if it is possible - rename it
Answer 2 : if impossible - rewrite MTSQL source code for this database to use another name to define MTSQL objects