Давненько не писал в блог. И, кажется, никогда еще такие годовые посты не писал.

Год был интересный и продуктивный

Начался он очень странно, в полночь 1-го января я был на трассе, по дороге в Красноярск из Канска, где мы год назад (31 декабря 2010 года) чудом нашли угнанную у нас ранее самодвижущуюся телегу. По авто вобщем-то никаких продвижений за год нет. Потрачены уйма времени и денег на преодоление российской бюрократии, на данный момент бюрократы побеждают. Зато поняли как все эти люди, на оплату которых уходят наши налоги, работают (точнее всячески пытаются не работать). Помогает еще немного переосмыслить, что же такое Россия, и как тут жить (и стоит ли тут жить).

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

Ну и, пожалуй, главная новость года – в ноябре мы с Машей переехали в Москву. Тут (чисто субъективное мнение конечно, как и всё, что я говорю) круче. Удобней и интересней.

За год проделано много работы, участвовал в проектах различного рода. Начиная от небольших интернет-магазинов и баз знаний для бедных украинских фермеров, заканчивая системой автоматизации деятельности группы крупных саморегулируемых организаций в области строительства, проектирования и др. Получил хороший опыт по управлению проектами среднего уровня (с командами по 5-10 разработчиков), по выявлению и анализу требований заинтересованных сторон.

И, пожалуй, за этот год я понял, что уже устал от разработки интернет-проектов и скучного однотипного кровавого энтерпрайза. Да и специфика этого рынка такова, что знаний много не требуется, конкуренция высока: за любой такой проект с радостью возьмутся миллионы индусов. Нужно двигаться дальше. Меня на данный момент очень интересует Business Intelligence. В рабочих планах на следующий год стоит развитие этого направления – в проектах нашей компании и/или в США. А может и в рамках наших проектов для заказчиков из США Как пойдёт.

А, про политику же надо сказать, забыл. Говно эта ваша политика. Не пишите законы, пишите код. А, впрочем, большинство хомячков и законы-то писать не умеет (как показало поверхностное исследование хомячков-противников строительства марганцевого завода в Красноярске), только в интернетах троллят.

Поздравляю с наступающим!

–

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/

Один из наиболее популярных видов генерируемого пользователями контента – оценки различных материалов. Рейтинги есть практически везде: на новостных сайтах, в блогах, социальных сетях, интернет-магазинах.

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

Иногда предлагается только два варианта: плюс и минус. По факту правда получается не два, а три: можно не голосовать вообще.

А иногда и такого разнообразия нет. В Facebook, к примеру, есть только кнопочки Like. То есть остается два варианта: нажать Like или не нажать.

Какая шкала лучше? Это сложный вопрос. Приходится искать компромисс между точностью и сложностью оценки. Нажать Like намного проще, чем выбирать оценку по 10-балльной шкале, но при этом объем информации, полученной от пользователя, также различается.

Здесь на помощь приходит статистика. Сотрудники YouTube проанализировали, как люди оценивают видео. Пользователи оценивали материалы по шкале от 1 до 5. И, как оказалось, подавляющее большинство оценок – это 1 и 5. Причем оценок 5 в разы больше, чем оценок 1.

Вобщем-то причины понятны. Люди ставят оценки в основном только если видео очень хорошее или очень плохое. Кроме того, суть оценок 1 и 5 хорошо понятна. А вот как понимать промежуточные оценки? Чем 4 отличается от 5 или от 3?

Выходит, что 5-балльная шкала – излишнее усложнение, и должно вполне хватать 2-балльной. Как, например, реализовано на StackOverflow.

А учитывая, что оценок 5 в разы больше – то может сгодиться и 1-балльная, как на Facebook. Но тут уже важно оценить, насколько понизится точность рейтинга.

Точность оценок становится особенно важна, когда речь заходит об использовании их для прогнозирования. Так, к примеру, Amazon использует оценки пользователей для системы рекомендаций товаров. А компания Netflix придает вопросам рейтингов настолько большое значение, что объявило приз 1 миллион долларов за алгоритм, который сможет повысить точность их прогнозов на 10%.

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

–

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/

Фиксирую лог своих разборок с SharePoint Напомню, одной из моих задач была разработка иерархического списка.

Один из опробованных вариантов решения – создание типа данных, унаследованного от Folder. Подробный туториал по построению иерархического списка на основе такого подхода можно найти тут:

http://weblogs.asp.net/sharadkumar/archive/2008/07/13/manage-hierarchical-data-in-sharepoint-lists-building-a-project-team-site-template.aspx

Этот подход как-то работает. И, учитывая предусловия, заданные автором этого туториала (обойтись без написания программного кода и без использования SharePoint Designer), решение неплохое. Но меня оно не совсем устроила. При этом у меня есть и лицензионный SharePoint Designer, и против программного кода ничего не имею. Поэтому идем дальше

Можно разработать Web User Control (ascx), отображающий данные в нужном нам виде. Это несложно. Вот тут описаны способы подключения web user controls к сайту SharePoint:

http://sharepointinsight.blogspot.com/2007/07/web-user-controls-in-sharepoint.html

http://jcapka.blogspot.com/2009/01/i-was-explaining-my-technique-of-using.html

А здесь довольно подробно о том, как программно доступаться к элементам списков:

http://www.sharepointdevwiki.com/display/public/Accessing+list+items+using+the+object+model

Еще один вариант, лучше чем web user controls в отношении повторного использования и удобства встраивания в сайт – создание WebPart. Ставим SDK, после этого в Visual Studio появляется кучка новых типов проектов в группе SharePoint.

Обратите внимание, что для того, чтобы создать новый проект для SharePoint необходимо, чтобы на машине был установлен SharePoint. А для его установки нужна серверная ОС. У меня на компьютере установлен Windows 7. Другая проблема, которая может возникнуть – это то, что имея Visual Studio 2010 будет проблематично делать решения для SharePoint 2007. Обе этих проблемы решаемы. Здесь подробный туториал:

http://www.dotnetmafia.com/blogs/dotnettipoftheday/archive/2010/07/15/using-visual-studio-2010-sharepoint-templates-to-deploy-a-web-part-in-sharepoint-2007.aspx

Создать проект без установленного SharePoint нельзя, но открывать уже существующие можно без проблем. Поэтому нужно просто иметь под рукой готовый пустой проект SharePoint. Такой проект можно найти в приложении к вышеуказанной статье. Чтобы проект был годен для SharePoint 2007 – удаляем из референсов проекта ссылки на библиотеки SharePoint версии 14 и добавляем референсы на библиотеки версии 12, которые можно взять из GAC на сервере, где установлен SharePoint 2007. Проверял, работает

Visual Studio автоматически собирает solution package (wsp), который можно разворачивать на SharePoint’е. Далее закидываем этот package на сервер и разворачиваем с помощью утилиты stsadm. Как это делать можно почитать тут:

http://www.sharepointnutsandbolts.com/2007/07/building-and-deploying-sharepoint.html

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

http://dyakov.design.officelive.com/hieviewwp.aspx

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

Написал этот пост по большей части чтобы ссылки не потерять и зафиксировать опыт. Но возможно кому-то будет полезно

–

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/

Для платформы ASP .NET мало хороших CMS. Еще меньше бесплатных хороших CMS. И совсем нет бесплатных хороших CMS для электронной коммерции

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

Коммерческие разработки вроде Kentico хороши, но стоят денег. А Sitecore вообще шифруется: цены я смог получить только после недельного ожидания и нескольких часов разговоров с их продажниками в Дании Минимальная версия SItecore вышла бы нам в 9900 евро. Максимальная что-то около 83000 евро.

Среди бесплатных CMS для электронной коммерции есть, пожалуй, лишь один серьезный продукт. Это nopCommerce. Российская разработка: разработчики из Ярославля. Open Source. Деньги берут за документацию и за право не ставить на сайте их логотип.

Функционал довольно мощный. Скидки, налоги, оплата, доставка, возвраты товаров, рейтинги, отзывы, форум, новости, статьи… Общий объем кода около 15 мегабайт, количество таблиц в БД превышает сотню.

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

Чудеса начинаются, когда нужно хорошенько кастомизировать магазин. Тут-то выясняется, что архитектура слегка страдает.

Например, что делать, если нужно добавить поле в какую-то таблицу? В Kentico, Sitecore или даже в бесплатной Umbraco для этого достаточно зайти в веб-интерфейс администрирования сайта в раздел “Developer” и отредактировать список полей нужной сущности. Что нужно сделать в nopCommerce для решения этой задачи? Процесс очень простой. Вот здесь он описан подробней.

1. Добавить свойство в соответствующий класс

2.Обновить методы репозитория (Update/Insert)

3. Добавить поле в таблицу базы данных

4. Обновить модель Entity Framework (edmx файл)

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

Добавить новую сущность? Без проблем, только шагов будет пять.

О качестве кода говорить не буду, лучше оцените сами Там, например, местами HTML собирается в code-behind из html generic controls. Хорошо хоть не конкатенацией строк. И кода этого 15 мегабайт.

Почему же всё так грустно в мире CMS для e-commerce? Есть что-то более приятное для e-commerce?

–

Павел Сурменок

http://surmenok.ru/, зеркало в ЖЖ: http://surmenok.livejournal.com/

http://pavel.surmenok.com/ – English-only version

Как-то внезапно в зону моих интересов (и интересов моих заказчиков) попал SharePoint. Сейчас мы (компания BetaCode) занимаемся проектом по внедрению SharePoint и интеграции его с Microsoft Team Foundation Server и Microsoft Project.

Одна из технических задач – создание иерархического списка Tasks с неограниченной вложенностью.

Провели исследования и выяснили, что подходов по созданию иерархий в SharePoint несколько.

Во-первых, можно создать несколько Lookup column: Parent1, Parent2, … , Parent10. И соответственно у элемента второго уровня вложенности задавать Parent1, у элемента третьего уровня – Parent2 и т.п. Далее в View делаем группировку по Parent1, Parent2 и т.п. Это как-то коряво, и это не даёт неограниченной вложенности.

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

Это очень просто реализуемый вариант. Но не лишен недостатков. Так, в стандартном View можно смотреть список только каждого уровня в отдельности. Т.е. при открытии списка видим только корневые элементы, при открытии кого-то из этих корневых – видим его дочерние элементы. В общем всё как обычно с папками. А хотелось бы сразу видеть дерево. Примерно как в TFS в запросах Iteration backlog.

В-третьих, можно добавить одну Lookup column Parent, с помощью которой задавать отношения Child-Parent между элементами. А View разработать свой. При этом придется раскуривать объектную модель SharePoint и написано некоторое количество хорошо отлаженного кода При этом хорошо бы воспользоваться толковым контролом для отображения иерархических списков. Например DevExpress TreeList или что-то подобное подешевле.

Возможно позже напишу более подробно о том, как эту задачу решать. Когда закончим.

–

Павел Сурменок

http://surmenok.ru/

http://pavel.surmenok.com/