IronPython. Ссылки.

Начинаем работать с IronPython.
http://blogs.gotdotnet.ru/personal/AlexanderByndyu/PermaLink.aspx?guid=71d5dcff-7833-4242-ac06-5388ad993acf

Entry point для того чтобы начать работать с IronPython в Visual Studio 2008.


Блог автора языка IronPython:
http://blogs.msdn.com/haibo_luo/default.aspx


IronPython: Grab the .NET Type
http://blogs.msdn.com/haibo_luo/archive/2007/09/25/5130087.aspx

Можно сказать entry point по IronPython/.NET interop. Очень мало, но наглядно :)


IronPython: Keyword Argument to Set .NET Property/Field
http://blogs.msdn.com/haibo_luo/archive/2007/10/02/5246577.aspx

Если кто-нибудь любит свеженькие конструкции C# вроде Object Initializer, то стоит просмотреть этот пост.


IronPython: Passing Arguments for a Call
http://blogs.msdn.com/haibo_luo/archive/2007/10/01/5230964.aspx

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


IronPython: Provide (or not) Argument for by-ref Parameter
http://blogs.msdn.com/haibo_luo/archive/2007/10/04/5284947.aspx

Вызов методов с ref-параметрами.


IronPython Cookbook
http://www.ironpython.info/index.php/Main_Page

Собрание материалов по IronPython.


SimplePrograms
http://wiki.python.org/moin/SimplePrograms

Своеобразные подсказки для тех, кто не хочет держать все время языковые конструкции в голове ;)


DLR Hosting and related stuff...
http://blogs.msdn.com/seshadripv/default.aspx

Релизная версия IronPython 2.0 работает поверх Dynamic Language Runtime. Если вам (не дай бог :) ) придется интегрировать хостинг Python-скриптов с вашим .NET-приложением, то тут можно почерпнуть максимум возможной информации.

Тест. Какая культура вам ближе?

Решил расслабить мозги после тяжелого трудового понедельника очередным тестом :)

Поздравляем!!! Вам ближе американская культура

Вас зовет земля свободы! Вам импонируют американское видение жизни и ценности "нового света".

Пройти тест

KDE 4.2. Релиз для всех.

Выпущен релиз KDE 4.2, который, как утверждают разработчики, уже готов для конечного пользователя.

До этого было два релиза, которые опционально включались в дистрибутивы, однако не были готовы к повседневному использованию простыми смертными.


Обзор. Можно ограничиться просмотром картинок :)
http://adymo.blogspot.com/2009/01/kde4-review-from-inside-out-part-1.html
http://adymo.blogspot.com/2009/01/kde-42-review-from-inside-out-part-2.html

Я с большим интересом наблюдаю за развитием ветки 4.x. Было даже несколько попыток установить его на свой дистрибутив Ubunut. Однако каждый раз я возвращался на стабильный Gnome. Хотя во многих моментах KDE 4.x мне нравится больше чем Gnome.

Отмечу так же что стабильный релиз KDE 3.5 мне вообще не нравился.

Знаю ли я русский язык?

Недавно наткнулся на нехитрый тест по проверке знаний русского языка.

Я проверил свои знания русского языка и получил четверку. Сходи, проверься?

Кроме информации выше, на странице был еще вот такое резюме по поводу моего результата:

Вы ответили на 6 из 8 простых вопросов. Не самый плохой результат на общем фоне. Скорее всего, вы неплохо знали русский язык в школе, просто было это давно, и теперь учебник Розенталя для вас заменяет грамматическая автопроверка в "Ворде". Гордиться вам особенно нечем, но для выживания в среде носителей русского языка этого вполне хватит. Таких, как вы, в стране, согласно опросу ВЦИОМа, - 21%.*


Какие мои личные выводы?

1. Мои учителя действительно были правы, когда ставили мне 4 на протяжении многих лет школы.
2. Спустя много лет мой мозг еще не успел засохнуть :)
3. Как гражданин Украины, который родился и вырос в этой стране, вполне могу себе позволить иметь оценку четыре по языку, который не является государственным.
4. По украинскому языку у меня тоже было четыре. Но это связано с тем что я говорю и думаю на русском языке, а мое любимое, [censored], государство считает что я (и еще 1/2 - 1/3 граждан) должен знать государственный язык.

XML в качестве DataSource для юнит тестов

Что-то в последнее время я вижу просто невообразимое обилие постов на тему TDD, что не может не радовать :)

Регулярно читая посты одного моего уважаемого коллеги по имени Mike Chaliy обнаружил заметку CSV у якості DataSource.

Вначале хотел оставить комментарий, но потом решил сделать это в виде отдельного поста.

Итак, Mike предпочитает CSV. Он достаточно подробно описал причины его решения, поэтому я решил немного пропиарить формат XML :)

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

На мой взгляд, у CSV формата в качестве источника данных для юнит тестов так же есть несколько недостатков, которые я привожу ниже:

1. Изменение структур данных. Добавляется новое либо удаляется старое поле. Приходится менять CSV документ. Причем придется чуть-чуть поколдовать над загрузкой документа в тот же Excel для того чтобы представить его в табличном виде. После чего нужно отредактировать эту таблицу и опять сохранить в CSV.

В случае с XML можно обойтись банальным Find/Replace в текстовом редакторе. Хотя это конечно дело вкуса. В любом случае нужно помнить об этом, поскольку для кого-то это может быть проблемой.

2. Обработка ошибок чтения. В .NET достаточно бедные средства для того чтобы работать с CSV форматом. С другой стороны, связка XML-файл + XSD-схема + класс-контейнер полученный от XSD.exe + чтение файла с валидацией по схеме выглядит очень привлекательно.

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

Если бы он обновлял XML документ он бы получил довольно внятное объяснение почему документ не может быть загружен.

3. Строгая типизация. Если использовать класс-контейнер, то сериализатор сам будет делать все приведения типов. В случае с CSV тебе придется этот код писать самому.

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


Таким образом, для меня выбор между CSV и XML практически эквивалентен с очень небольшим перевесом в пользу XML ;)

Начинающим на заметку. Два поста об оформлении исходного кода.

Фигурные скобки и их влияние на качество кода:

http://blogs.gotdotnet.ru/personal/ezakhareyev/CommentView.aspx?guid=77a8ef9b-19cb-401a-b832-ffac0ad7b3ad


В статье автор дает достаточно логичное обоснование почему фигурные скобки нужно расставлять именно так, как он предлагает :)



Точки выхода или немного о структурном программировании:

http://blogs.gotdotnet.ru/personal/XaocCPS/PermaLink.aspx?guid=72b2322a-6782-4ee6-b4e9-66df9678b56a

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


UPDATE:
Поправил вторую ссылку в которой текст и целевой url не совпадали.

Пожалуй отвечу на коментарии прямо в этот пост.

[mormat] Не знаю, почему в компании DevExpress другие гайдлайны (открывающая скобка на старой" строчке), неужели им удобно читать собственный код.. Сила привычки?

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


[mormat] Что касается множественных return-ов в теле метода, то помоему односторонняя совершенно статья. Где обоснование, где рассмотрение альтернативных точек зрения? Где плюсы, минусы? Я, например, знаю обратную точку зрения, что ряд валидирующих проверок в начале метода (с return-ами) сильно упрощает поддержку кода.

Честно говоря тут я более категорично настроен :) Если речь идет имено о валидации переданных данных, то тут стоит бросать исключения, а не использовать return. Хотя, уверен что ты имел ввиду скорее не валидацию параметров, а проверку на применимость метода.

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

К тому же если у меня идет некотороая проверка данных и лишняя вложенность уложняет код, то это можно решить следующим образом:

copy to clipboardподсветка кода

1. public ResultType DoSomething(SomeType value)  
2. {  
3.     // Если параметр невалидный, то этот метод прокинет исключение.  
4.     ValidateSomeType(value);  
5.   
6.     // В некоторых случаях бывает удобно инициализировать объект значением по-умолчанию сразу с его объявлением.  
7.     ResultType result;  
8.   
9.     // Если нам не нужно выполнять никаких действий над объектом, то мы просто выйдем из метода.  
10.     if (IsAcceptable(value))  
11.     {  
12.         ...  
13.     }  
14.   
15.     return result;  
16. }  

Миграция данных из одной таблицы в другую. Гибкое решение.

Буквально пару дней назад один мой знакомый, начинающий .NET программист показал мне код, который занимается переносом данных из одной базы в другую, причем паралельно делает преобразование типов:

copy to clipboardподсветка кода

1. string nsvid="";
2. string nsit="";
3. string type="";
4. string nzav="";
5. string ninv="";
6. string lim="";
7. string tochnost="";
8. string where="";
9. System.DateTime dtp = System.DateTime.Today;
10. Int64 pov=0;
11. System.DateTime dtn = System.DateTime.Today;
12. string texsos="";
14. for (Int64 i = 0; i <>
15. {
16. if (!bdt[int.Parse(i.ToString())].Is___п_пNull())
17. pp = long.Parse(bdt[int.Parse(i.ToString())].___п_п.ToString());
18. if (!bdt[int.Parse(i.ToString())].Is___свид_Null())
19. nsvid = bdt[int.Parse(i.ToString())].___свид_;
20. if (!bdt[int.Parse(i.ToString())].IsНаименование_СИТNull())
21. nsit = bdt[int.Parse(i.ToString())].Наименование_СИТ;
22. if (!bdt[int.Parse(i.ToString())].IsТипNull())
23. type = bdt[int.Parse(i.ToString())].Тип;
24. if (!bdt[int.Parse(i.ToString())].Is_Заводской__Null())
25. nzav = bdt[int.Parse(i.ToString())]._Заводской__;
26. if (!bdt[int.Parse(i.ToString())].Is_Инвентарный___Null())
27. ninv = bdt[int.Parse(i.ToString())]._Инвентарный___;
28. if (!bdt[int.Parse(i.ToString())].IsПредел_измеренийNull())
29. lim = bdt[int.Parse(i.ToString())].Предел_измерений;
30. if (!bdt[int.Parse(i.ToString())].Is_Класс__разряд__ц_д___погрешностьNull())
31. tochnost = bdt[int.Parse(i.ToString())]._Класс__разряд__ц_д___погрешность;
32. if (!bdt[int.Parse(i.ToString())].IsВладелецNull())
33. where = bdt[int.Parse(i.ToString())].Владелец;
34. if (!bdt[int.Parse(i.ToString())].IsДата_поверкиNull())
35. dtp = bdt[int.Parse(i.ToString())].Дата_поверки;
36. if (!bdt[int.Parse(i.ToString())].IsПериодичность_поверкиNull())
37. pov = long.Parse(bdt[int.Parse(i.ToString())].Периодичность_поверки.ToString());
38. if (!bdt[int.Parse(i.ToString())].IsДата_следующей_поверкиNull())
39. dtn = bdt[int.Parse(i.ToString())].Дата_следующей_поверки;
40. if (!bdt[int.Parse(i.ToString())].Is_Тех_состояниеNull())
41. texsos = bdt[int.Parse(i.ToString())]._Тех_состояние;
43. pdt.AddPriborRow(i+1, nsvid, nsit, type, nzav, ninv, lim, tochnost, where, dtp, pov, dtn, tochnost);
45. }
46. priborTableAdapter.Update(pdt);
47. pdt.AcceptChanges();

Достаточно беглого взгляда на этот код чтобы понять - реализация метода неоптимальна.

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

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

1. Делаем универсальный конвертер данных:

copy to clipboardподсветка кода

1. public static class ConvertUtils
2. {
3. public static object ToType(object originalValue, Type targetType)
4. {
5. if (targetType == typeof(string))
6. {
7. return originalValue.ToString();
8. }
9. if (targetType == typeof(int))
10. {
11. return int.Parse(originalValue.ToString());
12. }
14. throw new Exception(
15. string.Format(
16. "Type {0} is not expected.",
17. originalValue.GetType().FullName));
18. }
19. }

Если есть необходимость можно расширить метод до ToType(object originalValue, Type originalType, Type targetType)

2. Заводим "словарик" для преобразования данных:

copy to clipboardподсветка кода

1. var migrateDictionary = new SortedDictionary<string, type="">()
2. {
3. { "___п_п", typeof(long) },
4. { "___свид_", typeof(string) },
5. { "Наименование_СИТ", typeof(string) },
6. };
7. 
   

Можно расширить словарик до такого вида:

Ключ = Имя исходного поля + его тип
Значение = Имя целевого поля + его тип

3. И непосредственно реализация метода по переносу данных. Ни зависит ни от чего, разве что от ADO.NET, а именно типов DataRow, DataTable, DataSet :)

copy to clipboardподсветка кода

1. // Объекты DataRow естественно реально существуют :)
2. DataRow sourceDataRow = null;
3. DataRow targetDataRow = null;
5. foreach (var migrateInfo in migrateDictionary)
6. {
7. var columnName = migrateInfo.Key;
8. var targetType = migrateInfo.Value;
10. var sourceValue = sourceDataRow[columnName];
12. targetDataRow[columnName] = ConvertUtils.ToType(sourceValue, targetType);
14. }

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

Надеюсь что идея понятна. Не сочтите меня за велосипедостроителя. Я знаю что подобных примеров масса в интернете, и просто хочу донести эту мысль до тех, кто читает этот блог :)