понедельник, 31 января 2011 г.

Bugzilla

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

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

воскресенье, 30 января 2011 г.

Касяки 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 изучить и что такое генерики "<>" и т.д.

среда, 26 января 2011 г.

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

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

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

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

четверг, 15 июля 2010 г.

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)

среда, 14 июля 2010 г.

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

понедельник, 12 июля 2010 г.

NEW! Method declarations in Macro TSQL

Here is last submit info (Вот что было в последних обновлениях):


1) NEW method declaration support for interfaces
2) FIX _drop now can drop triggers
3) FIX procedure renaming applyed correctly (only in outer declaration)
4) FIX pseudo object '_' now dropped when core module loaded
5) NEW syntax shugar - allow call to dynamic sql in short style :

exec _ '<<< select * from {{@table}} where {{@field}} = ''{{@value}}'' >>>'
6) UPG addition comdivpreprocessor.x300_table_interface_parameters_embeder - adds parameters to interface definitions if not provided manually (@table and @useconstraints parameters)
7) NEW safe and simple procedures to ensure (create if not exists) of filegroups and files of database
8) NEW comdiv.mtsql.core.interfaces.sql - module - some our best practices of table schemas (especially for hibernate mapping), expressed as comdiv table interfaces


What is most interesting? (Что наиболее интересно?)
method declarations (Определения методов в интерфейсах)
Look at this code:
-- INTERFACE CREATING:
/*@
<name>comdiv_table_interface.code</name>
<field name='code' type='nvarchar(255)' constraint='not null unique default cast(newid() as nvarchar(255))' />
<method name="id">
        create function __ (@code nvarchar(255)) returns bigint as begin
            return (select top 1 id from THIS where code = @code )
        end
</method>
<method name="code">
        create function __ (@id bigint) returns nvarchar(255) as begin
            return (select top 1 code from THIS where id = @id )
        end
</method>
@*/
create proc _ as begin return end




-- INTERFACE USAGE
GO
if(object_id('__X') is not null drop table __X
GO
_table '__X'
GO
_interface '__X', 'code'
GO
insert __X (code) values ('a')
GO
select dbo.__X_id('a')           -- 10
select dbo.__X_code(10)      -- 'a'
GO


Significant changes:
1) methods a totally defined on declarative maner
2) automatical name generation - don't need to copy in method implementation (use pseudo name __ instead)
3) special 'keyword' THIS that means table to which interface is applyed

(RU)
Значимые изменения:
1) методы полностью формируются в декларативной части
2) автоматическая генерация имен - не надо дублировать в реализации метода, используется псевдо-имя __
3) специальное "ключевое слово" THIS - обозначает целевую таблицу, к которой применяется интерфейс

Macro T-SQL project published (en)

More than 10 years i'm working with MS SQL



Something was upgraded during this years, and MS SQL 2005 is exactly good server for many and many projects that we develop and support.



But working with PostGres, system programming on C#, Boo and others give as not very good thing to think about. It's that T-SQL is not so good language as we want it to be... Not much readable, with some ugly constructions and everyday 'snippets' to do some simple stuff.



We were'nt want to live with this forever and wait MS to give as something fantastic in SQL 2016, but:



  1. T-SQL is what it is - well complicated, but not extensible, not-declarational language and we cannot avoid it.
  2. I hate any code-preparing utils that you MUST to call if you want to apply some DSL - what if i want to call SQL from APP - i must to supply it with very_good_utility.exe? and call it ?
  3. Schema generator programs is far more ugly thing even than codegenerators...
  4. Using of .NET assemblies looks mo prety, but... it's hard to support too and cause it's own problems
  5. We like to solve problem in MS SQL 2005 itself and with T-SQL itself
In a moment we have 'evrica!'





Module we wrote is not a part of comercial order, is not selfish product, so I decide to publish it as open source.

Go to  http://code.google.com/p/macrotsql/.
Discussion at:





By using special stored procedures and DDL triggers (without any .NET assembly or custom tool) you'll get folloing framework:

  1. embeded XML documentation as in C#
  2. declarative attribute programming (inspired by C# and Boo mete-attributes)
  3. stored procedures and function SQL extensible preprocessor framework
  4. object-oriented support for table schema definition (very wanted after POSTGRE, inspired by prototype.js :) - we define some set (with inheritance) of 'interfaces' that then are applyed to target table (extends it)
  5. prepared set of preprocessors for some every day tasks:
  • tracing of proc enter and leave
  • wrapping procedure body in transaction
  • explicite (in text) line numbering (for quick finding place of error from error comment)
  • support fo  foreach macro block instead of ugly native  work with cursors (maybe worst thing in T-SQL)
Look at project, try it, send me feedback and patches. Wish that project will be usefull for you and you will be usefull for project :)