Заметки провинциального айтишника

Путешествие по Европам на автомобиле. Версия 2.0. День первый.

2011-09-28T11:47:00.000+04:00

Как известно, самый короткий путь в Словакию из Волгограда лежит через Украину. Поэтому выехали в субботу 6 августа. Нам надо было в понельник попасть в шенгенскую зону. Выехали около семи утра, с таким расчетом, чтобы часам к 13 попасть на погранпереход Новошахтинск - Довжанский. На погранпереходах сейчас поставили веб-камеры и наблюдение в них показало, что к часу дня в субботу с российской стороны народу мало. Наши ожидания не оправдались. Границу мы проходили 4 часа. никаких вопросов не задавали, все как обычно.
Дальше поехали в сторону Днепропетровска с тем, чтобы заночевать в Павлограде. Сильно сократила время окружная дорога в Донецке. В Павлогражде несколько мотелей и гостиниц, но мы остановились в гостинице "Химик", она несколько в стороне от трассы, зато, наерное лучший вариант. Итого 530 гривен за полулюкс на троих с завтраком и стоянкой.

Путешествие по Европам на автомобиле. Версия 2.0

2011-09-02T12:28:00.001+04:00

По итогам трипа хочу написать несколько постов. Для начала - итоги :)
Маршрут : Волгоград-Кошице-Липтовский Микулаш-Вена-Обертраун-Инссбрук-Леголэнд-Марианские Лазны- Трнава-Кошице-Волгоград
Время: 21 день
Расстояние: 7632 км.
затраченное топливо: 382 литра дизтоплива
максимальная скорость по GPS: 167 км/ч
Средняя скорость по маршруту 68 км/ч
Средство передвижения: Skoda Yeti 4x4 TDI DSG

Архитектура электронного правительства. Часть девятая - вводная для муниципалитетов

2010-09-23T09:29:00.002+04:00

После большого перерыва начнем разбираться с муниципалитетами. В Российской федерации принято разделение на два типа муниципалитетов: муниципальные районы и муниципальные городские округа. Хотя на самом деле все гораздо сложнее. С муниципальными районами все более или менее понятно, это сельские районы субъектов федерации, с небольшим населением (потому, что они сельские), часто с огромной площадью. А вот с городскими округами все сложнее. Это и, фактически, поселки, с количеством жителей до 50 тысяч и средние города, до полумиллиона жителей, и города-миллионники, в которых населения больше, чем в некоторых европейских государствах.

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

Для больших городов, возможно, выгодней, с точки зрения управляемости и денег будет построение своего собственного сегмента СМЭВ, а для небольших городов, сельских районов однозначно выгодней во всех смыслах строить свои сегменты в рамках некоего ЦОД регионального уровня.

Архитектура электронного правительства. Часть восьмая – облака над поселком

2010-07-07T10:24:00.004+04:00

Я решил специально остановиться на «облачном» вопросе. Не надо быть семи пядей во лбу для того, чтобы понять, что использование инструментов e-gov на уровне поселений, неважно первого типа или второго, будет минимальным. Причины этого вполне предсказуемые: лень, «отсутствие необходимости», ну и попросту сельским жителям сложно посетить сайт собственного поселения, да и у них свои заботы: корова недоена, уборка, посадка и т.д. Все это гораздо важнее, чем пнуть председателя сельсовета, чтобы он, наконец, вкрутил лампочку на фонарном столбе, если он – столб – вообще есть.

Вывод – разворачивать всю инфраструктуру, информационные системы - как минимум не выгодно, как с точки зрения денег, так с точки зрения трудозатрат. С минимальными потерями выйти из этой ситуации поможет парадигма облачных вычислений. Причем, именно с точки зрения оплаты за потребленные ресурсы. Вопрос теперь в том, где же взять это облако. Фактически это означает, что необходимо иметь облачные сервисы для субъекта федерации, которые будут обслуживать все поселения на территории (для примера: в Волгоградской области более 400 муниципальных поселений). Причем, подразумевая, что, потенциально, эти маленькие электронные правительства будут обрабатывать персональные данные, следует говорить о построении некоей смеси Government private cloud и Government public cloud, тут сложно говорить о терминологии. С одной стороны эти облака должны выдавать наружу внешние порталы поселений, с другой – они не должны выдавать беспрепятственно наружу системы обработки запросов граждан и внутренние порталы.

Построение такого облачного ЦОДа, с точки зрения первоначальных вложений, в глобальном смысле (не вдаваясь в особенности бюджетного устройства РФ), будет гораздо выгодней, чем развертывание 400+ отдельных серверов. Далее встанет вопрос в стоимости операционной деятельности. Боюсь, что такой ЦОД всегда останется дотируемым, даже если будет предоставлять услуги для поселений на возмездной основе. Тем не менее, стоимость операционной деятельности (ROI) облачного ЦОДа будет меньше совокупного ROI все поселковых серверов. Можно попытаться промоделировать все деньги, но я не буду делать этого в блоге J

Архитектура электронного правительства. Часть седьмая

2010-07-05T12:48:00.002+04:00

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

Тем не менее, проблемы с кадрами в таких администрациях остаются (имеется в виду, что администрации не только не могут взять на работу ИТ специалиста, но и найти приходящего - сложно), поэтому необходимо предусматривать возможность передачи обслуживания инфраструктуры, приложений на сторону. Не только в чистый outsourcing людей, но и использовать IaaS и SaaS.
Применение промышленной CRM, как основы для построения системы обработки обращений граждан в данном случае уже становится оправданной.
Внутренний портал выполняет функции средств групповой работы, а также простейшей системы документооборота.
Внешний портал является как представительством администрации поселения в Internet, так и точкой входа в систему обработки обращений граждан.

Архитектура электронного правительства. Часть шестая.

2010-06-29T12:07:00.003+04:00

Итак, начну с предложения муниципальному поселению первого типа. Для начала – что оно собой представляет – поселение первого типа. В терминах советской власти – это сельсовет. Сейчас это, фактически, от 3 до 5 человек во главе с выбранным начальником. Инфраструктуры чаще всего никакой, цели и задачи минимальны. Поэтому, даже минимальное предложение покроет все потребности. Но, тем не менее, это потребует от поселенческой администрации довольно больших, по их меркам, вложений в технику и ПО. В идеале все решение должно развертываться на одном серверном боксе, что по нынешним временам вполне возможно.
Так же следует учитывать практически абсолютное отсутствие в деревнях сколько-нибудь квалифицированных IT работников, поэтому решение должно предоставлять возможность публикации документов, обслуживание сайта и т.д., как минимум малоквалифицированному человеку. Именно поэтому, при наличии вменяемых каналов связи, имеет смысл говорить о выносе решения в «облако», т.е. либо использование IaaS, либо SaaS (а почему бы и нет?). Естественно, это возможно только при решении вопросов, возникающих на законодательном уровне.
Исходя из задач, предложение должно иметь следующий вид:

Следует иметь в виду, что система обработки обращений граждан в этом случае должна быть простейшей, не подразумевать под собой какой-то промышленной CRM.
Внутренний портал должен обеспечивать совместную работу специалистов администрации поселения: совместные календари, области документов, списки задач и т.д., так же внутренний портал должен предоставлять сервис персональных областей для работников администрации.
Внешний портал – это представительство поселения в Internet. Место публикации новостей, информации о поселении и т.д., а также входная точка для граждан в системе обработки обращений граждан.

Продолжение следует…

Архитектура электронного правительства. Часть пятая.

2010-06-28T12:46:00.002+04:00

Несмотря на мой предыдущий пост и смотря на законодательство РФ, на мой взгляд, стоит разделять предложения по построению ЭП, классифицируя территориальные образования по уровню власти. Для РФ это будет (я не беру во внимание федеральный уровень власти):

Муниципальное поселение
Муниципальное образование (район субъекта федерации/ муниципальный городской округ)
Субъект федерации

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

Муниципальные поселения:

Тип 1: сельские поселения в районах субъекта федерации
Тип 2: городские и поселковые муниципальные поселения. Пример: г.Жирновск Волгоградской области.

Муниципальные образования:

Тип 1: муниципальные районы и небольшие города подчинения субъекта федерации. Пример: Урюпинский район и г.Урюпинск (все таки столичный город, хоть и российской провинции) Волгоградской области.
Тип 2: большие города подчинения субъекта федерации, столицы субъектов федерации. Пример: г. Волжский Волгоградской области, Тольятти, Самара, Волгоград и т.д.

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

Итак, в зависимости от ранжирования территориальное образование будет получать предложение различной «тяжести»: от самого легкого для муниципального поселения первого типа, до самого тяжелого для субъекта федерации.

Продолжение следует….

Архитектура электронного правительства. Часть четвертая - красочная

2010-06-15T15:52:00.004+04:00

От общественно-политических изысканий перейдем к более приземленным - архитектурно-техническим.

На диаграмме представлена примерная архитектура, еще раз в кавычках, «электронного правительства».

А где же, спросите вы, система электронных государственных услуг, и всякие новые системы, если вдруг они понадобятся?
Все очень просто, отдельная система гоc.услуг – это фикция, она никому не нужна. Ведь гос.услуги, неважно каким образом они предоставляются, есть результат исполнения своих функций государственным органом. Соответственно за выполнение государственных услуг отвечают уже существующие наследованные системы, либо новые, которые будут создаваться для облегчения выполнения функций органа власти. А граждане будут отправлять запросы на получение услуги и отслеживать состояние заявки посредством цепочки [портал, соц. сервисы, система электронных коммуникаций] –> [шина данных и система исполнения бизнес-логики]->[наследуемые системы].

Продолжение следует....

Архитектура электронного правительства. Часть третья

2010-06-15T09:39:00.002+04:00

Для многих становится открытием то, что правительство или администрация субъекта РФ не является одним юридическим лицом. Комитеты, управления, министерства, аппарат Главы (Президента) – все они являются отдельными юридическими лицами, со всеми вытекающими последствиями. Причем министерства финансов или управления или комитеты (в разных субъектах называются по разному, но название сути не меняет) – живут, чаще всего, совершенно отдельной жизнью, со своими маленькими ЦОДами, со своими немаленькими бюджетами на ИТ и т.д.

Продолжение следует…

Архитектура электронного правительства. Часть вторая – экономическо-политическая

2010-06-10T12:09:00.002+04:00

Дальше перейдем от технических деталей к организационным. Вполне понятно и обоснованно, что обмен данными между различными ведомствами и, что подразумевается, между их информационными системами должен проходить в некоем стандартизованном виде. И тут (сюрприз, сюрприз!) сразу видно, что никаких стандартов нет. Логично поставить вопрос, кто будет делать стандарт, кто его должен соблюдать и кто за все это будет платить.

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

Вопрос – кто за все будет платить - не менее животрепещущий, и тут дело даже не в том, есть ли деньги или их нет. Экономически неэффективно строить инфраструктуру «электронного правительства» в каждом муниципальном районе, поселении или городе. Гораздо эффективней сделать некую общую инфраструктуру для субъекта федерации, где будут консолидированны все сервисы. И тут на сцену вступает закон 131-ФЗ и Бюджетный Кодекс Российской Федерации, которые прямо запрещают исполнять функции муниципалитетов за счет казны субъекта.

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

Продолжение следует….

Архитектура электронного правительства

2010-05-26T12:40:00.002+04:00

Можно рассматривать электронное правителтьство как нечто эфемерное и не применимое к реальной жизни, или как просто рекламный слоган. На мой взгляд, ЭП стоит рассматривать как некую информационную среду, интергрирующую разнородные наследованные информационные системы. Ни для кого не секрет, что в РФ информатизация именно правительственных органов на урове субъекта федерации находится не на самом низком уровне. Да, не все области деятельности подверглись воздействию ИТ, но, например, такие области как исполнение бюджетов, социальная защита в части пособий и т.д., т.е. все то, что так или иначе связано с деньгами – попросту не может быть выполнен вручную.

Итак, какие же компоненты нам нужны для того, чтобы создать такую информационную среду, условно называемую «Электронным правительством». Все зависит от задач, которые предполагает исполнять эта система. Как ни напыщено это звучит, но основная задача электронного правительства – информирование граждан о том, как исполняются те или иные функции правительства. Если мы хотим информировать, то нам нужно что-то, что мы должны показывать. И это что-то является абсолютно разнородным. Вывод такой, что это задача для BI. Использование BI подразумевает под собой наличие некоего централизованного хранилища данных, на основе которых будет проихведен анализ и отображение интересующей граждан информации. Второй компонент – система, которая будет собирать разнородные данные из наследованных систем и наполнять наше хранилище. Это задача, возможно, для ESB (Enterprise Service Bus).

Продолжение следует.

Про электронное правительство

2010-03-23T09:44:00.001+03:00

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

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

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

Последний день на госслужбе

2010-01-16T21:40:00.001+03:00

28 января будет мой последний день на госслужбе. Прошло 14 с половиной лет на этой работе, всякое было… Пора внести перемены :)

Silverlight RIA Services. Вопросы и ответы

2009-11-11T23:57:00.003+03:00

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

Итак, я попробую ответить на эти вопросы в этой статье.

Вопрос 1. Можно ли получить доступ к произвольным данным в приложении RIA Services?

Что бы ответить на этот вопрос, необходимо совершить небольшой экскурс в архитектуру приложения. В большинстве случаев RIA Silverlight приложение состоит из двух частей: клиентской части и серверной части. в каждой из частей за доступ к данным отвечает свой класс: в серверной части – наследник DomainService, а в клиентской части – наследник DomainContext. При этом нужно понимать, что DomainContext является proxy классом, который генерируется VisualStudio автоматически, после изменения и перекомпиляции DomainService класса. Таким образом, забота разработчика состоит в том, чтобы определить состав данных, методы, реализующие выборку данных, а также, если нужно, методы выполняющие изменение данных. И еще, DomainService классов может быть как несколько, так и один.

Итак, начнем с определения состава данных. Состав данных определяется с помощью классов-сущностей (entity). При описании классов нужно придерживаться определенных правил:

поля или свойства классов должны иметь один из сериализумых типов: символьные, числовые, логические и т.д.
в состав передаваемых данных входят только public поля или свойства.
Как минимум одно поле или свойство класса должно быть помечено атрибутом [Key].

Пример определения такого класса:

public class ClientClass
   {
       [Key]
       public Guid ID { get; set; }
       [Display(Name = "Наименование клиента", Description = "Поле для ввода наименования клиента")]
       [StringLength(100, ErrorMessage = "Не больше 100 символов")]
       public string Name { get; set; }
   }

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

Второй этап – реализация методов выбора данных. Здесь также существуют довольно простые правила. Методы должны возвращать класс, который имеет реализацию интерфейса IQueryable, и методы должны быть членами класса – наследника DomainService. Примеры определения методов:

public List<GeneralInfo> GetInfo(DateTime dt)

public Collection<CreditRow> GetRows(DateTime dtb)
public IQueryable<CreditDetail> GetDetails(Guid RowID)

Как реализуется собственно выборка данных, из каких источников, с применением каких технологий – выбор разработчика. Могут быть применены сервисы WCF, вебсервисы, произвольные СУБД, вообще что угодно. Дело разработчика выбрать данные, сформировать из них один или несколько экземпляров класса-сущности и поместить их в результат.

Необходимо отметить еще один способ доступа к данным, который может быть применен в том случае, если необходимо вернуть, например, количество элементов в выборке. Заводить класс-сущность с одним единственным полем невыгодно, поэтому в этом случае можно применять сервисные операции. Что же такое сервисные операции? Это методы класса DomainService, которые помечены атрибутом [ServiceOperation], и которые могут возвращать простой тип. Пример объявления и реализации такого метода:

[ServiceOperation]
public int GetCount(DateTime dt)
{
    return GetRows(dt).Count;
}

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

Третий этап – реализация методов редактирования данных. DomainService поддерживает три вида изменения данных:

Добавление
Редактирование
Удаление.

Разработчик должен реализовать соответствующие методы. Рассмотрим, как это делается. Чтобы класс знал, какие методы должны быть вызваны в случае редактирования или удаления эти методы должны быть объявлены в соответствии с соответствующими правилами. Правила таковы:

Для операции добавления название метода должно начинаться с префикса Add или Insert, либо метод должен быть помечен атрибутом [Insert]
Для операции редактирования название метода должно начинаться с префикса Update, либо метод должен быть помечен атрибутом [Update]
Для операции удаления название метода должно начинаться с префикса Delete, либо метод должен быть помечен атрибутом [Delete]

единственным параметром всех этих методов должен иметь тип соответствующего класса-сущности. То есть объявление метода, которые редактирует сущность будет выглядить примерно так:

public void UpdateOrderClass(OrderClass order)

Реализация методов – на усмотрении разработчика. Закончив все три этапа, можно сказать, что организация доступа к произвольным данным завершена.

Вопрос 2. У меня есть несколько таблиц в базе данных, я организовал доступ к данным с помощью ADO.NET Entity Model. Но мне нужно передать в клиентскую часть результат запроса, объединяющий две таблицы, причем не все поля из таблиц. Как это сделать?

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

Вопрос 3. Когда я разрабатываю приложение, то под ASP.NET Development server у меня все работает, но когда я размещаю приложение на хостинге или на “боевом” сервере, то приложение в браузер загружается, а данных нет, никаких ошибок не видно. Что делать?

Ответ в том, что каждый раз надо рабираться с ситуацией. Основных причин, по крайней мере, две. Первая - приложение в IIS не сконфигурировано таким образом, чтобы запросы, ответы были в кодировке utf-16. Нигде об этом в прямую не написано, но это так.

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

Вопрос 4. Что нужно, чтобы развернуть RIA Siverlight приложение?

Ответ прост. Нужен .NET Framework 3.5 SP1 Runtime, IIS6, IIS7, IIS7.5. Для IIS6 нужно прописать MIME типы для .xap, xaml. и xbap.

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

Silverlight webcast

2009-10-28T16:35:00.004+03:00

Собственно вот, первый камень в огород webcast (http://www.smalldevteam.com/demo/default.html).

Тема: различные методы доступа к данным в приложениях Silverlight RIA Services

Принимаются предложения и замечания.

ASP.NET и Silverlight

2009-10-06T22:59:00.003+04:00

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

Можно говорить, что Silverlight - это замена Flash, которая не подходит для бизнес-приложений, и т.д., что нет этого на линуксе и прочих юниксах (что не совсем так, смотрите проект Moonlight). Но вот есть интересные такие результаты:

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

Естественно, нужно понимать, что RIA Silverlight - это слой представления, в который может быть перенесена и часть логики (при желании), но, фактически, backend-ом может быть что угодно. (смотрите несколько статей 1, 2, 3 Сергея Орлика) в том числе и облака. Точно можно сказать, что уж в Azure все это работает просто на ура. Правда Azure не доступен в РФ, в смысле за него нельзя платить в РФ, я так понимаю, что тут проблема не техническая, а на поле законодательства.

2009-09-14T20:27:00.002+04:00

Кризис это отличная причина ничего не делать и ныть о том, что кризис и нет ничего в светлых тонах. А так же отличное время порезать зарплату и выгнать неугоднях людей. Задрало!

Кризис среднего возраста

2009-08-15T22:19:00.002+04:00

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

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

Родные пристают с расспросами, что же мне подарить, а у меня как в Греции, все есть: несколько тубусов со спиннингами, приличный фотоаппарат и так далее J. К сожалению, новую работу они мне подарить не могут.

Про стартапы 3

2009-06-07T22:03:00.001+04:00

Итак, наш сервис http://www.smalldevteam.com выходит на стадию бета тестирования.

Работают сервисы управления ошибками (bug tracking) и сервис управления версиями. Скоро будет работать третья компонента – Task Management.

Работа с ошибками организована на сайте. А вот работа с системой управления версиями - с помощью отдельной утилиты, которая на днях будет доступна в разделе Downloads. Утилита требует первоначальной регистрации на сайте.

Описание ошибок, которые вы найдете (а они обязательно будут), присылайте на betareports@eadsoft.com

Про стартапы 2

2009-05-08T14:14:00.001+04:00

Стартап потихонечку выходит из тени. Собственно вылез только самый маленький кусочек- http://www.smalldevteam.com

Желающие принять участие в бета-тестировании и/или имеющие предложения – оставляйте комментарии с координатами.

Про стартапы

2009-04-14T16:54:00.001+04:00

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

Лицензионная чистота оказалась очень несложным делом. Это программа BizSpark от Microsoft. Каких-то особых телодвижений не понадобилось, просто вменяемо объяснить, что я собираюсь делать.

В общем, ждите анонсов и бета-тестирования.

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

UI, как его надо делать

2009-03-06T22:05:00.001+03:00

Хорошая штука – набор UI паттернов, практически на все случаи жизни.

http://quince.infragistics.com/

Сижу дома, болею

2009-03-04T22:09:00.001+03:00

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

Собственно документ вот он (http://habrahabr.ru/linker/go/53269/). Это небольшое исследование на тему, куда инвесторы готовы вложить деньги

Надоело о кризисе

2009-01-27T23:16:00.001+03:00

Все о кризисе, да о кризисе. Надоело!! За этим кризисом просмотрел несколько интересных и, на мой взгляд, полезных вещей.

Live расширяется. Теперь доступен SkyDrive и, что более важно – Office Live, который сделан на основе Sharepoint. Немного конечно урезано, но для личного использования или для использования небольшой группой – просто отлично.
Я вообще большой поклонник SharePoint, и активно его использую в работе, не только как файловую свалку нового поколения, но и как средство совместной работы. И это становится понятным потому, что основная моя работа сейчас – работа клерка по сути своей , хоть это мне ОЧЕНЬ не нравится.
мы используем Sharepoint и как средство сбора и агрегации каких-то небольших и несложных форм, безо всяких сложных вещей вроде Forms Server и т.д. Все это без программирования и с удобной интеграцией с основным инструментом клерка – Outlook J

Мысли о кризисе 2

2008-12-09T15:33:00.002+03:00

Я как в воду глядел о сокращениях. Кризис докатился и до государства. Во всяком случае до субъектов РФ. Поступления в бюджет сократились в два раза, остатков на счетах по нескольку миллиардов нет. Все съели. И мысль о сокращениях расходов госаппарата появилась в умах. Сокращают поездки, содержание (покупку всякой ерунды) и собираются сокращать работников. Так что ждем официального уведомления, благо заявлений по собственному тут не просят.