Silverlight: Открываем Насыщенные Интернет Приложения для мира Open Source

Silverlight: Enabling Rich Internet Applications for the Open Source World.
Да, вот скачал себе туториал на 44 странички с таким вот громким названием. В общем то, туториал не плохой, поэтому его и рекомендую. Рассказывает, как создавать приложения на Silverlight без Visual- и прочих студий, а на родном, для Java-разработчиков, Eclipse.

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

Английский язык, как же его fucking сложно изучить

Когда я учился в школе, я любил уроки английского языка. Сравнительно с другими предметами, я почти всегда делал домашние задания и, следовательно, мог похвастаться своими оценками, начиная с 5-го класса. В общей сложности, как обычный школьник, а потом и в колледже, я изучал английский на протяжении 10 лет. Тогда было много свободного времени, часть которого можно было посвятить на чтение англоязычной книги, мануалы по какой-нибудь технологии в программировании и т.д.
Но, когда я устроился на работу, понял, что нихрена то я и не знаю английского языка.
По крайней мере, очень сложно понять разговорный английский, общаясь с американскими заказчиками. Я понимал слово через десять, и приходилось связывать эти 10% распознанного текста какой-нибудь своей логикой, чтобы ответить что-то в тему.

Через год, я понял, что, в принципе все не так сложно. По работе мы, как оказалось, общаемся шаблонами. Когда слышишь или читаешь одну и ту же шаблонную фразу несколько раз, то поневоле запоминаешь ее, и уже используешь самостоятельно:
“This bug is reproduced…”, “An exception has occurred”, “At this point [%some behavior here%]”.
Проработав уже более 3-х лет над одним и тем же проектом, я хорошо понимал устный английский заказчика, мог вести электронную переписку и иногда вставить свои 5 копеек в устной форме, при разговоре по Skype, например.

Но, к сожалению, все таки, к большому сожалению, такие живые общения Skype, или в лучшем случае, когда приезжает заказчик, проходят очень редко. А ведь они дают тот необходимый толчок для совершенствования языка. Нет, обычно все вопросы решаются по e-mail. Это очень сильно экономит время, но не дает мне лишний раз попрактиковаться в английском.

Проблемы

1. Основная проблема в том, что на изучение английского не хватает желания, если хотите, то не хватает грубого пинка под зад. Кто сказал что я не понимаю английского? Я прекрасно понимаю, что там написано на MSDN или на CPAN. Я отлично ориентируюсь в том чего от меня хотят, и могу объяснить, что я буду делать в переписке по ы-мейлу. В устной форме я могу связать 3 слова, и помочь себе жестикуляцией. Кроме того, устным английским мне приходится пользоваться очень редко.
2. Не хватает времени. С одной стороны, тут все таки больше желания опять таки не хватает. Ну не могу я посвятить кучу времени на изучение английского. Лучше я какую-нибудь книгу умную почитаю, или разберусь с какой-нибудь интересной технологией, или напишу что-то свое. Не могу я выделить время и в будние дни, чтобы ходить на курсы по английскому – мне работать надо.
3. Не хватает практики. Ну, хорошо, вот изучу я английский, и с кем я буду общаться? А если не буду общаться, то деградирую нафиг и забуду все.

Решения

Пинком под зад для меня служит тот факт, что английский просто необходим для моего дальнейшего профессионального роста. Английский открывает множество дверей, в том числе и на западный рынок, где и крутится большая часть IT-шной работы и IT-шных зеленых денег. Возможно через пять лет я открою свое дело, либо буду работать удаленно, так почему бы мне прямо сейчас не подготовить необходимую базу для общения с заказчиками?

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

• Когда мы едем в поезде/метро/маршрутке на работу и с работы. Сколько времени теряем? Я теряю 1 час в день, т.е. 5!!! часов в неделю.
• Когда ничего не хочется делать, когда просто устал и развалился перед телевизором или лег отдохнуть.
• Когда делаешь тупую рутинную работу, не требующую полного вмешательства мозга.

Как не дать пропасть этому времени попросту? Слушать аудио записи. Подкасты или специализированные курсы для изучения английского языка.
И это действительно работает. По крайней мере, это самый эффективный метод изучения английского для лентяев.

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

ESL – English as a Second Language, рассчитаны специально на слушателей, изучающих английский:

English as a Second Language Podcast
Самый известный ресурс. Обновляются очень часто. Аудио материалы бесплатны и очень хорошего качества.
Слушать: ESL Podcast 472 – Feeling Nervous About Public Speaking


Fun English Lessons
Это действительно веселые подкасты. Очень рекомендую. Слушаю их обычно утром, чтобы поднять настроение перед работой.
Слушать: 119 - E-Commerce


Преимущество этих подкастов в том, что они не устаревают, я скачал себе весь архив и слушаю каждый подкаст.
Характерной чертой ESL подкастов является то, что на «простом» английском объясняется более сложный английский. Кроме того, в ненавязчивой форме рассказывается про культуру и жизнь американцев, что, несомненно, помогает понять их лучше.

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

SE-Radio
Слушать: Episode 133: Continuous Integration with Chris Read


The Command Line Podcast
Слушать: TCLP 2009-04-22 Interview: Jonathan Zittrain


Deep Fried Bytes
Слушать: Episode 30: New Ideas for the Web with Thomas Krotkiewski


Herding Code
Слушать: Herding Code 43: Javier Lozano on the "M" in MVC


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

В первую очередь, это Будам. Этот человек живет в Америке, и очень много рассказывает про американский образ жизни в своей ленте За cool жизнь.
Слушать: #85 American Woman


И рекомендую ленту career_english Влада Воробьева.
Слушать: Russian-english typical phrases and expressions - THINK


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

Секретное, самое мощное и самое сложное оружие

Это перевести какую-нибудь англоязычную статью. На самом деле на перевод небольшой по объему статьи, можно потратить кучу времени. Основную сложность тут составляют так называемые идиомы, ведь дословно каждое слово переводить нельзя! Вот и тратишь время на распознавание этих идиом и гугление значений, чтобы не получилось, как в старом анекдоте:

В российской глубинке фестивальный показ зарубежных фильмов.
На экране идет американский фильм...
Герой на экране:
- How do you do
переводчик:
- Как вы это делаете?
Ответ:
- It's all right
переводчик:
- да все правой,правой.

Красота string.Empty или скорость“”?

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

static void Main(string[] args)
{
  string token = "      ";
  switch (token.Trim())
  {
      case string.Empty:

          break;
  }
}

Я очень удивился, когда компилятор выдал ошибку, что в строке
case string.Empty:
требуется констанотное вырожение.
Лезем в Object Browser и смотрим декларацию string.Empty:

public static readonly string Empty в классе String.

Почему не константа?! Может быть, есть какое-то сверх объяснение, связанное со сверх оптимизациями и прочей магией?
Погуглив на это тему, обнаружил замечательную статью:
string.Empty Example and Issues in C#
Оказывается, что даже при использовании в конструкции if, сравнение со string.Empty работает в два раза медленнее, чем с константной пустой строкой "":

=== string.Empty benchmarked code ===

if (string.Empty == null)
{
  throw new Exception();
}

=== Constant string benchmarked code ===

if ("" == null)
{
  throw new Exception();
}

=== Benchmark results ===
  Second loop was completely compiled out before runtime.
  1000000000 iterations.

string.Empty loop: 637 ms
"" loop:           319 ms [faster]

Я не отказываюсь от использования string.Empty, но теперь призадумаюсь о том, стоит ли использовать такую запись пустой строки на конкретном участке кода.

Слушаем C Sharp ;)

Так вот, какой ты, C Sharp ;)

Кстати, таки не плохо поют ;) Послушать: C-Sharp Band

Строки в C# и внутренний пул

Я не знаю, почему это людей так беспокоит вопрос о том, где формируются строки с C# и так радует ответ, что они формируются во внутреннем пуле(Intern pool). Но, видимо это очень важно, так как такие вопросы присутствуют в большинстве статей по подготовки к собеседованию по C# и такой вопрос, я сам на него отвечал, есть в тесте BrainBench.

Мне, честно говоря, было пофигу, где эти строки формируются и хранятся, главное, что это все работает. Я воспринимал это как аксиому, которую, точнее, нужно сформулировать так: «Все строковые литералы компилятор C# помещает во внутренний пул».

Но, когда я писал код, похожий на следующий код, то немного призадумался:

string name = textReader.ReadLine();
switch (name)
{
    case "Bob":
        Console.WriteLine("Hello, Bob!");
        break;
    case "Vasya":
        Console.WriteLine("Privet, Vasya!");
        break;
    default:
        Console.WriteLine("O_o Vasya!");
        break;
}

Ведь в переменной name содержится строка, прочитанная из файла в момент выполнения, так как же эти строковые кейсы работают? Они же, по идеи, должны сравнивать ссылки. А чтобы моя переменная name совпала хотя бы с одним этим кейсом, то она тоже должна быть интернирована (помещена в пул), как и строковые литералы.

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

Я наивно пытался похачить это дело, но все-таки ничего не получилось:

using (TextReader tr = File.OpenText(@"C:\temp\strings.txt "))
{
    string string1 = tr.ReadLine(); // This is a string
    string string2 = tr.ReadLine(); // This is a string
    string string3 = tr.ReadLine(); // This is another string

    Console.WriteLine("First try:");
    Console.WriteLine(" string1={0}\n string2={1}\n string3={2}", string1.GetHashCode(), 
                                                                  string2.GetHashCode(), 
                                                                  string3.GetHashCode());
    StringBuilder sb = new StringBuilder();
    string internPool = "Intern Pool";
    sb.Append("Intern ").Append("Pool");
    Console.WriteLine("Second try:\n string1={0}\n string2={1}", internPool.GetHashCode(), 
                                                                 sb.GetHashCode());

    Console.WriteLine("Third try:\n string1={0}\n string2={1}", internPool.GetHashCode(),
                                                                sb.ToString().GetHashCode());

}

Текстовый файл:

This is a string
This is a string
This is another string

Вывод первой попытки, как не странно string1 и string2 равны:

First try:
string1=2035671784
string2=2035671784
string3=164170943

Вывод второй попытки! Ага все таки не равны! Но, на самом деле и типы тут разные:

Second try:
string1=-1024490162
string2=58225482

Вывод третий попытки. Приведем-ка это это добро .ToString. :( Все таки ссылки равны:

Third try:
string1=-1024490162
string2=-1024490162

Upd. Вот что значит дописывать код в 2 часа ночи :) На самом деле, ссылки не равны, а .GetHashCode это не правильный способ. Спасибо, Alex, за комментарий.

Если добавить следующие строки кода, то выясняется, что ссылки действительно не равны:

Console.WriteLine("Ref Eq string1 and string2 = {0}", object.ReferenceEquals(string1, string2));
Console.WriteLine("Ref Eq string2 and string3 = {0}", object.ReferenceEquals(string2, string3));
// и...
Console.WriteLine("Ref Eq internPool and sb.ToString() = {0}", object.ReferenceEquals(internPool, sb.ToString()));

Результат:

Ref Eq string1 and string2 = False
Ref Eq string2 and string3 = False

Ref Eq internPool and sb.ToString() = False

Экономим байты исходного кода. Реализация алгоритма QSort

Однажды, когда я проходил трейнинг по C#, нам было задано домашние задание, одним из пунктов которого было реализовать алгоритм быстрой сортировки(QSort) на C#. По достаточно хорошему описанию алгоритма на страницах Википедии, я все-таки реализовал алгоритм по-своему, но решил продолжить поиск наиболее «короткого» решении. И я его нашел. Следующий код написан на языке Perl, и это то, к чему нужно стремиться:

sub qsort {
  return () if !@_;
  return (qsort(grep { $_ < $_[0] } (@_)[1..$#_]), $_[0],
          qsort(grep { $_ >= $_[0] } (@_)[1..$#_]));
}

Превосходно! Реализация алгоритма наглядна и прекрасно запоминается. Я попытался переписать исходный код с Perl на C#, и вот что у меня получилось:

public static List<T> QSort<T>(List<T> sourceArray)
    where T : IComparable<T>
{
    if ( sourceArray.Count == 0 )
    {
        return new List<T>();
    }
    T firstItem = sourceArray[0];
    sourceArray.RemoveAt(0);

    List<T> greaterList = new List<T>();
    List<T> lessList = new List<T>();
    List<T> sortedArray = new List<T>();

    
    foreach (T item in sourceArray)
    {
        if (item.CompareTo(firstItem) < 0) lessList.Add(item);
    }

    foreach (T item in sourceArray)
    {
        if (item.CompareTo(firstItem) >= 0) greaterList.Add(item);
    }

    sortedArray.AddRange(QSort(lessList));
    sortedArray.Add(firstItem);
    sortedArray.AddRange(QSort(greaterList));
    
    return sortedArray;
}

Вроде бы ничего, по крайней мере, задание сдал. Но, вот недавно я увидел следующее решение на C#:

public static IEnumerable<T> QuickSort<T>(this IEnumerable<T> list)
    where T : IComparable
{
    if (!list.Any())
    {
        return Enumerable.Empty<T>();
    }
    var pivot = list.First();
    var smaller = list.Where(item => item.CompareTo(pivot) <= 0).QuickSort();
    var larger = list.Where(item => item.CompareTo(pivot) > 0).QuickSort();

    return smaller.Concat(new[] {pivot}).Concat(larger);
}

Кто короче?! ;)

10 навыков, которые потребуются разработчикам в ближайшие 5 лет

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

1. Один из «Большой Тройки» (.NET, Java, PHP)

Если в мире разработки не произойдет радикальных изменений (скажем, на Редмонд упадет астероид), то разработчикам будет необходимо знать по крайней мере один, из «Большой Тройки» языков программирования и платформ разработки: .NET (VB.NET or C#), Java, или PHP в самом ближайшем будущем. И недостаточно знать одного лишь синтаксиса языка программирования. Поскольку проекты охватывают самые разнообразные функциональности, вам будет просто необходимо знать Фреймворки и библиотеки, связанные с необходимым функционалом, более углубленно.

2. Насыщенные Интернет Приложения (RIA)

Любили вы RIA, или ненавидели, но Flash используется сейчас не только для создания мультфильмов про политиков, которые поют глупые песенки. Flash нарастил дополнительную функциональность по для создания приложений, используя такие технологии как Flex и AIR. Конкуренты Flash, такие как JavaFx и Silverlight, также разрабатывают подобные фичи и повышают производительность. И чтобы укрепить связь между этими вещами, HTML5 объединит себе всю функциональность RIA, включая соединение с базами данных, и ставя этим официальную печать W3C на технологии AJAX. И это значит, что в ближайшем будущем, различия RIA платформ будут очень сильно сглажены.

3. Веб-разработка

Веб-разработка никуда не уйдет, по крайней мере в ближайшее время. Многие разработчики игнорируют Веб, или по крайней мере знакомы лишь с теми основами, которые предоставляют им фреймворки. Но, компаниям требуется все больше и больше людей, умеющих работать с теми технологиями, которые лежат ниже уровня фреймворка. Так что JavaScript, CSS, и HTML будут успешны на протяжении еще 5-ти лет.

4. Веб-службы

REST или SOAP? JSON или XML? То, что выбор решения зависит от проекта, сложность работы разработчика возрастает без использования технологии Веб-служб. Даже те сферы, где раньше использовались ODBC, COM, или RPC, постепенно переходят на использование Веб-служб. Разработчики, которые не умеют работать с Веб-службами, найдут себя в сфере поддержки и баг-фикса старых проектов.

5. Социальные навыки

Все что сейчас происходит, движется к увеличению видимости IT внутри и снаружи предприятия. Разработчики постепенно вовлекаются в сферы, не связанные непосредственно с разработкой, для получения от них ответов на существующие вопросы. Скажем, финансовый директор не может изменить правила бухгалтерского учета, без помощи IT для внесения изменений в необходимые системы. Точно так же, как нельзя изменить работу кол-центра, без внесения необходимых изменений в CRM-систему предприятия. Также, клиентам часто необходимо работать с разработчиками напрямую, чтобы убедится в том, что их требования были учтены. Пойдут ли разработчики изучать ораторское искусство, или начнут изучать книгу по типу «Как завоевать друзей и влиять на людей»? Нет. Но, разработчики, которые все-таки сделают так, будут более ценны для своего начальства и высоко ценится на рынке труда.

6. Один динамически и/или функциональный язык

Такие языки, как Ruby, Python, F#, Perl и Groovy это не совсем мейнстрим, но хорошие идеи в них есть. Скажем, LINQ из .NET Framework – это прямой потомок функциональных технологий программирования. Python и Ruby стают более востребованы в некоторых областях, благодаря фреймворку Ruby on Rails и хорошей поддержки программирования под Silverlight. Изучение одного из этих языков не просто улучшит ваше резюме, но и расширит ваш кругозор. Каждый признанный и уважаемый разработчик, рекомендует изучить по крайней мере один динамический или функциональный язык программирования, чтобы познать новые способы мышления и решения задач. И из личного опыта, могу сказать вам, что это действительно работает.

7. Гибкие методологии

Когда Agile только появилось в мейнстрим разработке, я и много других людей, которых я знаю, отнеслись к этому скептично. Это скорее всего был рефлекс по защите традиционного подхода, отбрасывая прочь все инструменты, которые бы привели к анархии. Но, время шло, и идеи, лежащие в основе Agile стали лучше определены и четче выражены. И многие команды уже используют и экспериментируют с Agile. Конечно же, Agile не является той панацеей, которая спасет проект от провала, но гибкие методологии действительно успешно используются во многих проектах.
Разработчики с пониманием Agile и успешной работы с инструментами гибкой разработки будут востребованы на рынке труда. И этот спрос будет расти в ближайшие 5 лет.

8. Знание предметной области

Вместе с гибкими технологиями, команды разработчиков все больше и больше рассматриваются как партнеры для других проектов. Это означает, что разработчики, понимающие проблемную область, способны сделать очень значимый и ценный вклад. Вместе с Agile, разработчик, который может сказать, «Вот сюда, мы можем легко добавить такую-то функциональность, и это будет очень значимо для нас», или «Эй, это требование не соответствует тому, что хотят видеть наши пользователи», будет действительно выделяться. И чем больше разработчики будут сопротивляться знаниям предметной области, неоспоримо то, что компании будут отдавать предпочтение тем, кто понимает хотя бы основы предметной области.

9. «Гигиена» разработки

Несколько лет назад, много коллективов разработчиков не использовали такие инструменты как: баг-трекинговые системы, системы контроля версия и другие подобные инструменты. Они просто работали со своей IDE и все. Но, благодаря новым подходам по интеграции, и новым инструментам, таким как Microsoft Visual Studio Team System и появлению высококачественных инструментов с открытым исходным кодом, коллективов не использующих такие инструменты стает все меньше. Но, разработчикам уже недостаточно знать только то, как можно залить код в репозиторий, или забрать его оттуда, или как использовать виртуальные машины для создания тестовой среды. Они должны быть аккуратны, и уверены в том, что они надлежащим образом координируют свои действия с действиями команды. Те люди, которые копируют все на свою персональную флешку, не документируют то, каким элементам задачи соостветсвуют изменения кода и тому подобное, не приветствуются в традиционных коллективах, и еще больше не приветствуются в Agile-командах, полагающихся на тесную координацию и коммуникацию между членами команды.

10. Разработка для мобильных устройств

В конце 1990-х годов, Веб-разработка росла и получала всеобщие признание, и постепенно начала утеснять традиционные настольные приложения во многих областях. В 2008-м году, развитие мобильной разработки уже покинуло стартовую площадку, и на протяжении следующих 5-ти лет, она станет все более и более важной. Конечно, есть множество подходов разработки программного обеспечения для портативных устройств: создание веб-приложений, RIA, и приложения, которые работают непосредственно на устройстве. Независимо от того, какой путь вы выберете, добавление умений по разработке для мобильных устройств в вашу копилку мастерства обеспечит вашу востребованность на рынке труда, в будущем.


От себятинка:
Одиннадцатым пунктом я бы добавил в этот список «знание английского языка», этот скилл был востребован и раньше и будет востребован еще и через пять и пять десятков лет. Если, конечно же, на Редмонд не упадет огромный астероид ;)
Подобные переводы, отнимают кучу моего времени, но вместе с тем, они прокачивают мой уровень английского языка, и просто приносят удовольствие.
Поэтому, могу посоветовать тебе, Читатель, ищи что-то интересное на английском, и переводи на свой родной язык.

Оригинал статьи:
10 skills developers will need in the next five years

Про автора оригинальной статьи:

Justin James is an employee of Levit & James, Inc. in a multi-disciplinary role that combines programming, network management, and systems administration.

.NET, NHibernate, Castle ActiveRecord и генераторы кода. В поисках истины

Я работал раньше с ORM’ами на других языках программирования, и должен сказать, что я, как человек ленивый и стремящейся всеми возможными способами упростить свою работу, уже прочно привык к их использованию. Так что, вместо того, чтобы писать деревянные и тривиальные запросы для CRUD-операций и кучу JOIN’ов для реализации связей между таблицами, я предпочитаю заюзать хороший ORM и не париться по этому поводу.
Так как проект пишется на ASP.NET с возможной поддержкой Mono, то мне было необходимо, чтобы этот ORM работал с MySQL, чтобы был хороший генератор кода для классов записей, и чтобы он был как можно проще для изучения. Ну, не хочу я месяц тратить на изучение какой-нибудь технологии, без которой, я в принципе, могу и обойтись.

NHibernate

Первое, что мне бросилось в глаза для .NET – это NHibernate (рус. http://nhibernate.ru/). Очень мощный ORM, используемый достаточно большим количеством людей. На то, чтобы разобраться в азах этой штуковины, я потратил целый вечер, и понял, что это вещица это действительно мощная, но не такая уж и простая и содержит кучу нюансов. Это я понял, пролистав «купленную» книгу NHibernate In Action и просмотрев несколько отрывков из скринкастов по NHibernate. Слишком сложно. В топку :(

ActiveRecord

Бороздя необъятные просторы Интернета, я все-таки нашел то, что мне нужно. Это Castle ActiveRecord. Хорошо, что он построен на базе NHibernate, так что мне не пройдется отказываться от функционала NHibernate. Но, это проще чем NHibernate! И это то, что нужно для моего проекта. Ура! Меня не пугает то, что последний релиз (точнее релиз кандидат) был полтора года назад, я смотрю на то, что в Сети есть много позитивных отзывов по поводу Castle ActiveRecord. Кроме того, я немного работал с ActiveRecord в Ruby, и уверен, что для меня не составит труда быстро изучить, как использовать реализацию ActiveRecord на C#.

Генераторы кода

Уйму времени потратил на то, чтобы найти тулзу, которая бы сгенерировала мне код для моих ActiveRecord классов. Ситуацию осложняло то, что мне нужно было сгенерировать классы, по готовой БД, под управлением MySQL. Перепробовал кучу генераторов кода, но одни отказывались работать с MySQL, другие отказывались работать с MySQL. Хотел уже впасть в панику, и перегнать БД из MySQL в SQL Server, и уже от туда сгенерировать нужные классы. Но, проблема разрешилась. Нашел вот это:
Caragen Tool - the Castle Active Record Autonomous GENerator tool, которое прекрасно поддерживает работу с MySQL.

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