Сравнение 72 реализаций языков программирования

Сравнение 72 реализаций языков программирования:
http://www.opennet.ru/opennews/art.shtml?num=21974

Прямая ссылка на картинку с визуальным отчетом:
http://gmarceau.qc.ca/blog/uploaded_images/size-vs-speed-vs-depandability.png

Легенда к визуальному отчету из которой видно что нижний левый угол это идеальные языки программирования:
http://gmarceau.qc.ca/blog/uploaded_images/size-vs-speed-vs-depandability--context-3.png

Субъективные выводы по визульному отчету:
- Java существенно медленнее и несколько менее удобный язык чем C#
- Perl по скорости быстрее чем Python, а Python практически такой же по скорости как и PHP
- OCaml и luajit выглядят как идеальные языки. Я только не пойму luajit это Lua + Jit Compiler или как? :)

Каким должен быть правильный BL и DAL?

Не так давно нашел на ряд постов, которые сформировали у меня определенное видение решения классической задачки по передачи данных через ряд уровней - Data access layer -> Business layer -> Presentation layer.

Первым был пост Repository is the new Singleton от Oren Eini aka Ayende Rahien.

В этом посте Ayende говорит что ему не очень нравится непосредственно сам паттерн Repository, более того от отмечает что в большистве случаев этот паттерн еще и не совсем правильно используют.

Дествительно, с появлением LINQ и NHibernate/LinqToSql/ADO.NET Entity Framework подход к получению данных довольно сильно изменился.

И я придерживаюсь того мнения что нужно постепенно уходить от практики написания огромного количества методов вида GetCustomer(id), GetCustomerWithAddresses(id) и начинать использовать механизм запросов даже на верхних уровнях.

Если этого не делать, то мы очень быстро прийдем к достаточно некрасивому Data access layer'у - Kobe – Data Access done wrong.

В своем следующем посте - "The DAL should go all the way to UI" Ayende развивает идею и очень наглядно показывает какую цену приходится платить за неудачную реализацию Data access layer'а.

Действительно, если делать sorting и paging по-честному, через Business Layer, то приходится вручную писать кучу методов, которые похожи друг на друга как близнецы браться, что как раз нарушает принцип DRY (Don't Repeat Yourself).

Подход Ayende мне показался очень уместным, однако меня смутило отсутствие ограничений по извлечению даных на UI-уровне. Возможно, я параноик, но я бы хотел все вызовы по извлечению данных прокидывать через Business Layer. Как минимум это даст возможность прикрутить Caching/Logging/Security на query-методы.

В ответ на пост Ayende, другой блоггер Justin Etheredge сделал пост в котором привел достаточно удачную на мой взгляд реализацию paging'а и сортировки.

В результате, однозначно для себя я решил несколько моментов:
- Классы IRepository должны быть максимально небольшими и простыми
- При получении данных необходимо иметь возможность строить цепочку из filtering, paging, sorting, поскольку это дает намного больше гибкости
- Presentation Layer не должен работать с чрезмерно богатым интерфейсом, этот уровень должен использовать только то, что предоставляет ему Business Layer
- Все большие либо нетривиальные запросы стоит инкапсулировать в отдельные Query-объекты

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

SQLite для .NET разработчика. Ссылки.

Краткое описание на Wikipedia:
http://ru.wikipedia.org/wiki/SQLite

Обычная энциклопедическая статья, которая в общих чертах описывает функциональность этой встроенной СУБД. Очень радует лицензия продукта, которая Public Domain.


Официальный сайт SQLite
http://www.sqlite.org/

.NET программисту особенно тут делать нечего. Однако стоит прочитать две статьи в разделе Documentation - "Appropriate Uses For SQLite" и "Distinctive Features" чтобы иметь четкое понимание того, как именно позиционируется данный продукт.


SQLite Management Tools
http://www.sqlite.org/cvstrac/wiki?p=ManagementTools

Утилиты, которые позволяют управлять и выполнять запросы к базе SQLite

SQLite Converter Tools
http://www.sqlite.org/cvstrac/wiki?p=ConverterTools

Утилиты для конвертирования форматов других баз данных в формат SQLite и, наоборот.


SQLite Wrappers
http://www.sqlite.org/cvstrac/wiki?p=SqliteWrappers

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


System.Data.SQLite
http://sqlite.phxsoftware.com/

Наиболее развитый на мой взглять ADO.NET Data Provider для SQLite.

На официальном сайте можно отметить следующие интересные возможности этого проекта:
- Полная поддержка стека ADO.NET 2.0
- Поддержка .NET, .NET Compact Framework, Mono
- Поддержка ADO.NET Entity Framework, который доступен в .NET 3.5
- Design-Time поддержка в Visual Studio 2008
- Есть возможность шифрования базы данных

Для того чтобы распространять .NET проект, в котором используется база данных SQLite достаточно включить в него сборку System.Data.SQLite.dll, которая сама уже содержит оригинальную библиотеку.
Кроме того, можно использовать альтернативный вариант распространения - включать в дистрибутив приложения сборку System.Data.SQLite.dll из каталога ManagedOnly + оригинальную sqlite3.dll.


[UPDATE 2009-11-26]

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

Насчет ссылочной целостности в SQLite. Действительно, неделю назад обнаружил в документации что по-умолчанию в SQLite не включены FK Constraints. Да, не фонтан. Пусть даже это и встроенная СУБД, но я бы не отказался от такого полезного механизма контроля.

По ссылке ниже описывается как можно проверить включены ли они или нет и что нужно сделать чтобы их таки включить:
http://www.sqlite.org/foreignkeys.html

Из документации видно, что в будущих релизах FK Constraints могут быть включены.

Плюс еще довольно полезная информация по поводу того, чего SQLite не умеет из SQL92 стандарта:
http://www.sqlite.org/omitted.html

Пока для себя расставил такие приоритеты:
- если размер дистрибутива важен, и можно принебречь остутствием ряда продвинутых фич, то я предпочту SQLite;
- требовать уж очень высокой скорости работы от встроенной СУБД думаю что не стоит;
- Embedded Firebird выгодно отличается от SQLite возможностью с нее "соскочить" на полновесную Firebird. Предполагаю что это будет максимально безполезненно;
- Еще подумываю об необходимости использовании ORM + встроенная БД. Тогда и поставщиков БД можно будет менять как перчатки. Ну или почти...

Доступ к DreamSpark по студенческому билету для украинских студентов и аспирантов

Если ты студент и у тебя есть студенческий билет, то ты можешь получить ряд продуктов бесплатно:
Visual Studio 2008
Visual Studio 2005
XNA Game Studio 3
SQL Server 2008 Developer
Windows Server 2003
Windows Server 2008 Standard
Expression Studio 2


Подробности тут:
Доступ к DreamSpark по студенческому билету для украинских студентов и аспирантов

Необычный подход к написанию юнит тестов

Обнаружил довольно необычный подход к написанию юнит тестов у автора вот этого поста:
Test Driven Design и Test First Development -- в чем разница?

Меня привлекло то, что тест класс представляет из себя наследник тестируемого класса.

Приведу пример классического и альтернативного подхода (пример из документации NUnit).

Тестируемый класс:

namespace bank
{
 public class Account
 {
   private float balance;
   public void Deposit(float amount)
   {
     balance+=amount;
   }

   public void Withdraw(float amount)
   {
     balance-=amount;
   }

   public void TransferFunds(Account destination, float amount)
   {
   }

   public float Balance
   {
     get{ return balance;}
   }
 }
}

Тест, написаный при помощи "классического" подхода:

namespace bank
{
 using NUnit.Framework;

 [TestFixture]
 public class AccountTest
 {
   [Test]
   public void TransferFunds()
   {
     Account source = new Account();
     source.Deposit(200.00F);
     Account destination = new Account();
     destination.Deposit(150.00F);

     source.TransferFunds(destination, 100.00F);
     Assert.AreEqual(250.00F, destination.Balance);
     Assert.AreEqual(100.00F, source.Balance);
 
   }
 }
}

Тест, написанный с помощью альтернативного подхода с наследованием:

namespace bank
{
 using NUnit.Framework;

 [TestFixture]
 public class AccountTest : Account
 {
   [Test]
   public void TestTransferFunds()
   {
     this.Deposit(200.00F);
     Account destination = new Account();
     destination.Deposit(150.00F);

     this.TransferFunds(destination, 100.00F);
     Assert.AreEqual(250.00F, destination.Balance);
     Assert.AreEqual(100.00F, this.Balance);
   }
 }
}

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


Лично у меня возникает вопрос. А стоит ли вообще так писать тесты?

У меня сходу возникли следующие мысли насчет альтернативного подхода:
+ Наследование позволяет протестировать protected методы
+ Я могу написать helper-методы в тест классе, который будет активно работать с protected методами и свойствами
- Наследование дает бОльшую связность между тестовым и тестируемым классом
- Наследование скорее всего завяжет мне руки в SetUp/TearDown методах
- Если класс sealed, то о подходе с наследованием можно забыть
- Когда я пишу классический тест-метод, то я получаю лаконичную документацию к своему коду в виде маленьких примеров
- Когда я пишу классический тест-метод, то я использую класс точно так же как это делает production-код
- У класса Account будет аж два клиента - production code and unit tests, что как правило будет положительно отражаться на его интерфейсе


Очень интересны ваши мнения на этот счет.

Тест. Какой вы ученый?

Очередное баловство на тему тестов.

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

Как правило это играет мне на руку, хотя иногда все-же делает меня занудой. :)

О, да вы - физик.

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

Пройти тест

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-приложением, то тут можно почерпнуть максимум возможной информации.