Архитектура ИТ решений. Часть 2. Архитекторы

С предыдущей частью статьи можно ознакомиться, перейдя по ссылке

III ОПРЕДЕЛЕНИЕ ПОНЯТИЯ АРХИТЕКТОР

Врач может похоронить свою ошибку, архитектор – разве что обсадить стены плющом. Фрэнк Ллойд Райт.
Зачастую в ИТ отрасли, говоря об ИТ архитекторе, подразумевают продвинутого разработчика, способного самостоятельно спроектировать, а главное реализовать большую сложную систему. А иногда попросту полагают, что это следующая ступенька в профессиональной иерархии разработчиков. Например, начал молодой специалист свою карьеру разработчика, ему присвоили скромное, но почетное звание Junior. Он учится, развивается профессионально, растет над собой и коллегами, и ему, в качестве компенсации за труд и упорство, торжественно присваивается звание Middle. Но он неугомонный и дальше не останавливается в развитии, совершает ряд подвигов, самоотверженно взвалив на себя ответственность за принимаемые решения. Глядишь, и его уже удостаивают высочайшего звания Sinior. А дальше? А если он не желает почивать на лаврах успеха и хочет развиваться, ему что присвоят под звуки фанфар генеральское звание Архитектора? Так ли это? Специально ИТ архитекторов, насколько мне известно, не готовят в вузах. Чаще всего архитекторы получаются путем селекции из уже маститых специалистов в какой-либо ИТ области, «прокачивая» дополнительными знаниями до определенного уровня. Кстати существует профессиональный стандарт квалификационных требований системных архитекторов (5), на основании которых архитектору может быть присвоен один из шести квалификационных уровней. Будем использовать этот стандарт в ходе нашего рассмотрения темы, чтобы не упустить ничего важного в работе ИТ архитектора. ...Далее...

Моделирование бизнес-функций

Введение

Три проекции одного объекта на три разных плоскости – это не объект. Это его чертеж. Все три проекции позволяют инженеру представить деталь. Для этого надо соотнести точки на чертеже с точками в пространстве. Этому навыку способствует обучение начертательной геометрии. Ровно то же можно сказать про проекционное моделирование. Только обе проекции на пространство и на время позволяют представить то, что хотел сказать модельер. Для этого надо научиться корректно моделировать 4-Д пространство-время, а затем корректно соотносить эти проекции друг с другом. В данной статье я приведу практический пример такого рода моделирования. Для кого-то это будет достаточно непривычно. Кому-то, наоборот, покажется все слишком очевидным.

Моделирование партий товара

Начнем с моделирования привычного нам объекта — попробуем смоделировать лес. Есть 4-Д объем, который Иванов трактует как объект типа лес. Для моделирования этого факта создается информационный объект (ИО), моделирующий этот 4-Д объем. Далее создается ИО, моделирующий представление Иванова об этом 4-Д объеме. Этот объект связан с моделью 4-Д объема связью «что представляет», с моделью Иванова «кто представляет» и с моделью типа объектов – лес «как представляет». Читать дальше →...Далее...

7 лет работы, 2 млн отрезов и 150 километров чеков: еще немного о надежности железа в современных магазинах



Мы продолжаем разговор об инфраструктуре в сфере ритейла. Требования к использующемуся здесь железу серьезно отличаются от тех, которым должны соответствовать «потребительские» гаджеты или офисная техника. Сегодня в нашем блоге рассказ об этих жестких стандартах надежности на примере контрольно-кассовой техники (ККТ, бывших фискальных регистраторов) — устройств, без которых невозможна работа современного магазина. Читать дальше →

На шаг ближе к С++20. Итоги встречи в Торонто

Несколько недель назад состоялась встреча международного комитета по стандартизации C++. На ней люди (в основном) не разменивались на мелочи и совершили несколько больших шагов на пути к С++20.

image

Главные новости:

  • Расширению Concepts быть в C++20!
  • Ranges, Networking и Coroutines/сопрограммы: выпущены в эксперимент в виде TS.
  • Модули: черновик TS готов.

Что всё это значит, как это упростит написание кода и что было ещё — читайте под катом.
Читать дальше →

[Перевод] XBRL: просто о сложном − Глава 4. Отчет XBRL

4. Отчет XBRL


В этой главе мы рассмотрим отчеты XBRL. Как и прежде, основное внимание уделяем тому, что можно сделать, а не как это делается.


Отчет (instance document) содержит факты и ссылается на таксономию для придания фактам смысла:


image


Факты могут быть простыми (item) или составными (кортеж, tuple). Все простые факты в отчете имеют контекст, напр. финансовый год или начало отчетного периода. Все используемые контексты содержатся в самом отчете.


Схематически состав отчета можно изобразить следующим образом:


image


В следующих разделах мы более подробно рассмотрим составные части отчета.

Читать дальше →

Как запутать аналитика — 5. Понятийный аппарат

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

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

  1. При помощи статических объектов (стул)
  2. При помощи динамических объектов, сохраняющих параметры своей динамики (вращающийся двигатель)
  3. При помощи динамических объектов, не сохраняющих постоянными параметры своей динамики – операции (операции и события)

Читать дальше →

Как запутать аналитика. Часть третья. Глаголы и числителные

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

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


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

[Из песочницы] Все новое — это хорошо забытое старое

Вереница фреймворков и библиотек по очереди восседающих на троне трендов JavaScript мира это уже не новость. Разработчики из других областей даже подшучивают над нами на этот счет.

Вот и мне, в процессе работы, пришлось попрыгать по различным библиотекам и фреймворкам — qooxdoo, jQuery, Ext JS, Backbone.js, Knockout.js, Ember.js, Angular, React.

Не всегда выбор того или иного фреймворка был добровольный, модель outsource и outstaffing накладывает определенные ограничения на мою работу. Я думаю люди из этой же области поймут меня.
Читать дальше →


Последние посты