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

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

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


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

• Бизнес архитектура
• Архитектура информационных систем (потоки данных)
• Технологическая архитектура

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

Бизнес архитектура, она же Enterprise, является представлением того, как эффективно воспроизвести цели бизнеса и стратегию путем создания, улучшения и объединения ключевых требований, принципов и моделей для успешного развития бизнеса и достижения поставленных целей. Определение взято из английской википедии.  Архитекторы уровня Enterprise должны ориентироваться на бизнес потребности и проводить анализ потоков данных, т.е. покрывают два указанных пункта. Архитекторы уровня Solution занимаются технологическими аспектами проектов. Так же стоит упомянуть не обозначенных здесь Infrastructure Architect, людей, которые занимаются глобальным развитием и анализом технических возможностей по реализации проектов.

Как вы не знаю, но я себя на этой картинке узнал. Ведь, согласитесь, когда проектируется архитектура приложения, все красиво, логично и соответствует лучшим мировым практикам. Но в процессе работы, сталкиваясь с ограничениями предъявляемыми архитектурой, мы зачастую думаем: «Вот здесь немножко нарушу, это ведь сэкономит мне час времени разработки. Ну а потом, как будет время, поправлю». Но, почему-то, это время так никогда и не наступает. На мой взгляд, единственным способом заставить себя, как программиста, следовать разработанной архитектуре, это научить среду разработки все отклонения и костыли показывать как ошибки компиляции. В этом случае, если код плох, он сразу будет исправлен, ну а если архитектура устарела, то будет исправлена она. Т.е. в хранилище кода всегда будет код соответствующей запланированной архитектуре.
Пара слов, о том, что будет подкатом:
1. Небольшая преамбула.
2. Восстановление архитектуры по имеющемуся проекту.
3. Настройка Visual Studio и TFS для автоматического контроля архитектуры.
Под катом много картинок и желание все описанное попробовать.

Нет, это статья не об игре про заражённый вирусом Манхэттен и его мутантов. Речь пойдёт о прототипах другого рода — прототипах программного обеспечения.

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

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

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

Эпиграф: Верблюд — это лошадь, сделанная по всем требованиям заказчика.

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

Опытные и слаженные команды в России есть, а вот методологии управления требованиями — единой, прозрачной и удобной в использовании — до сих пор нет. Даже в одной организации от проекта к проекту меняются инструменты и методы управления требованиями, роли участников процесса, и, как следствие, нашим организациям не хватает «зрелости» — гарантии повторяемости проектных процедур со стабильно высоким качеством выдаваемых результатов.

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

1. Формирование структуры задач.
2. Поиск литературы в каталогах.
3. Сбор, обработка и систематизация информации.
4. Формирование списка литературы.
5. Составление плана по вехам.
6. Определение предмета исследования.
7. «Summary» для научного руководителя.

Я рад приветствовать вас, дорогие читатели.

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

Скажу сразу — я не задаюсь целью мотивировать или призывать к каким-либо правилам эффективной работы, т.к. все слишком индивидуально, чтобы давать подобные советы, но я постараюсь обратить ваше внимание на некоторые, на мой взгляд, интересные детали, лежащие в основе принципов проектирования, которые заметил и осмыслил на собственном опыте. Отмечу также, что статья будет актуальна не только IT-шникам, но и абсолютно всем категориям читателей.

Декларативный подход и MDA ахритектура имеют целый ряд преимуществ, позволяющих существенно сократить издержки на разработку и поддержку информационных систем (ИС: CRM, WMS, Project Management, etc). Этот подход уже используется в ряде продуктов (таких как 1С, например). Тем не менее, декларативный подход в них используется для решения слишком узкого круга задач. В этой статье мы рассмотрим преимущества декларативного подхода, покажем как можно значительно расширить область его применения в построении ИС, проверим построенную модель на реальных задачах и продемонстрируем работу прототипа.

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

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

Иногда очень хочется быстро найти нужный файл. С учетом того, что файлов — сотни тысяч, а ты не знаешь ни его названия, ни содержания, ни типа — ничего. Зато приблизительно знаешь категории. И хочется его быстро вычислить и сразу же отредактировать и записать.
На сегодня удобных кросс-платформенных open-source файлопомоек с прямым доступом к файлам — НЕТ.
Далее речь пойдет не о медиабиблиотеке и не о semaweb — а о простой и удобной системе управления громадной файлопомойкой с прямым доступом к файлам.

Слишком часто стала мелькать в западных блогах и твиттере аббревиатура “DCI”. Меня удивил тот факт, что на хабре по данной тематике почти нету информации, лишь в Ruby NoName Podcast S04E09 упоминалось об этом. Любопытство взяло вверх, и я решил узнать об этом загадочном слове побольше. В процессе поиска я наткнулся на хорошую статью, написанную на английском моим земляком, Виктором Савкиным. Данная статья без обильной теории, на практических примерах показывает, что из себя представляет DCI. Далее повествование будет идти от лица Виктора.

Задача

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

Имеется несколько удаленных объектов на просторах страны (Украина) электрифицированных, но не имеющих простых технических возможностей для подключения интернета. Объекты, как правило, расположены так что про 3G или WiMax заикаться не приходится. Доступен только GPRS. Нужно иметь возможность мониторить температуру в нескольких помещениях этих объектов. Причем желательно если не в реальном времени то с минимальной задержкой. Усложняется все еще тем что объекты хоть и недвижимость, но возможны ситуации что будет переезд. Поэтому капитальные методы установки оборудования отпадают.

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

Тренды будущего, которые меня интересуют. Тут я немного помечтаю, можно?

1. Распределенное роботизированное производство

В связи с российскими большими расстояниями, пробками на дорогах и качеством самих дорог весьма актуальным становится распределенное производство:
— создается интернет-сервис сбора заявок на изготовление деталей/прототипов
— менеджеры принимают оплату и заявки в виде чертежей либо моделей, делают необходимые уточнения по способу производства, допускам и пр, при необходимости подключают моделеров для создания 3D-модели
— уточненную заявку и оплату работ они направляют в центры обработки, находящиеся наиболее близко к расположению клиента. В центрах обработки находится современное ЧПУ оборудование (3D-принтеры, фрезеры, токарные станки, граверы, гибка металла, шлифовка-полировка, изготовление печатных плат, сборка и монтаж и пр), плюс операторы. Деталь/прототип изготавливается.
— после изготовления деталь/прототип отправляется клиенту по кратчайшему пути с помощью службы доставки
— процесс изготовления клиент может наблюдать онлайн (трансляция осуществляется вебкамерой)
— интерфейс системы геймифицирован (см. п.2)
— клиент, приславший фото или видео использования созданной вещи в своей работе, получает приз.

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

Взгляд на функциональные требования к интеграционной системе

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

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

Основное назначение сетей ZigBee – связь между устройствами в автоматизированных системах. Области применения сетей ZigBee – самые различные. Типы и назначение связываемых устройств – также весьма разнообразны. Связь может устанавливаться между выключателем и светильником в «умном доме», приборами учета и сервером сетевой обслуживающей компании, датчиком движения и пультом охраны. Возможно, просматривая этот топик, Вы, сами того не подозревая, пользуетесь сетью ZigBee – многие беспроводные мыши с USB адаптером 2,4 ГГц соответствуют ZigBee RF4CE specification.

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

Вступление

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

Здесь и далее имеются в виду компоненты в смысле частей одного процесса. Компоненты, являющиеся отдельными процессами или сервисами, работа с которыми идет через RPC или еще как-то, здесь не рассматриваются. Хотя в большой мере все нижесказанное относится и к ним.

Пример первый:
Мне нужен компонент, давно разработанный и протестированный в другом отделе. Подхожу к разработчику. Завязывается диалог:
— Вот мне нужна вот эта штука. Как мне ее использовать в своем проекте?
— Да, вот нужно залить проект из CVS вот по этой метке. Скомпилить. Получится либа, и вот с ней нужно линковаться.
— Ок, спасибо.
Выкачиваешь проект. Компилишь. Вылезает куча ошибок, не хватает каких-то инклудов. Начинаешь выяснять. Оказывается для сборки проекта надо выкачать из CVS еще кучу проектов, их тоже собрать. Некоторые собираются стандартно студией, некоторые с бубном, вроде autoconf, make и иже с ними. Все. Собралось. Начинаются проблемы с линковкой. Не линкуется одно, второе, третье. Сторонних библиотек не хватает. В итоге — куча потерянного времени на непроизводительный труд и вникание в использованные библиотеки, сторонние компоненты и технологии.

Данная короткая заметка будет полезна людям, занимающимся автоматизацией инженерных систем(ИС) зданий и сооружений. Я заметил, что на сайте есть люди знающие о компании «Болид» и ее интегрированной системах охраны – «Орион». Но буквально совсем недавно я узнал. Что ИСО «Орион» это не единственная рих азработка. Оказывается товарищи из славного города Королёва разработали свою SCADA и контроллер для автоматизации ИС здания. О них вам в вкратце и хотел бы рассказать в данной заметке.

Я работаю программистом более 5 лет (web), и хотел бы поделиться методикой, которая экономит силы, время и помогает автоматизировать процесс проектирования.

Методика основана на объектно-ориентированном проектировании, но несколько необычна. Зато имеет очевидные плюсы:
— в идеале, программирование по CORE сводится к описанию задачи (код близок к бизнес-логике)
— чётко разделяет систему на слабосвязанные компоненты
— легко автоматизируема, позволяет генерировать осмысленный код

Почему методика называется CORE и как это расшифровывается? Отчасти потому, что у меня тяга к красивым названиям. По буквам:
Context — контекст вычислений (что инициировало вычисления)
Object — объект, который производит вычисления
Request — действие, которое нужно совершить, чтобы объект смог продолжить вычисления
Event — событие, которое происходит с объектом

Плюсы по сравнению со стандартными способами разработки:
— ускорение стадии проектирования за счёт формализованной схемы проектирования
— ускорение стадии разработки за счёт умной генерации кода
— автоматизация создания юнит-тестов
— неглючная реализация бизнес-логики практически любой сложности
— простая поддержка кода
— простота совместного владения кодом

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

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

Доброго времени суток, хабраюзеры.
Как-то, года три назад, гуляя по центру Санкт-Петербурга (сам из Екатеринбурга), я подумал — почему центр Петербурга в разы приятней? Сравнил с Москвой, Афинами, другими крупными городами… Пришёл к промежуточному выводу, что человеку необходимо место для прогулок и широкая перспектива.

Полный же вывод сформировался чуть позже, когда мы шли с другом уже по нашему городу. Он немного технарь (в плане интереса к точным наукам), но скорее музыкант и художник. Он говорил об архитектуре: «Одно с другим не сочетается! Они вообще смотрят на окружающие дома?!» Я думал о системологии или, когда не говорят о науке, о системном подходе.
Тут в голове промелькнула мысль: «А что, если… Хотя почему если?! Город — это система, её нужно проектировать, а не развивать по мере необходимости». Я поделился мыслями с другом. Он их поддержал. Так бы всё и забылось, если бы не объявление о каком-то конкурсе, который уже исчез из названия.

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