Эта статья — ознакомительное руководство по сборке Docker-образов приложений с помощью нашей Open Source-утилиты dapp (подробнее о ней читайте в анонсе). На примере двух простых приложений (с одним образом) рассмотрим, как могут быть задействованы некоторые из основных возможностей dapp и какой результат они дают.
Рубрика «Анализ и проектирование систем» - 87
Практика с dapp. Часть 1: Сборка простых приложений
2017-08-23 в 8:26, admin, рубрики: continuous delivery, continuous integration, dapp, devops, docker, Анализ и проектирование систем, Блог компании Флант, системы сборки
Управление памятью в Python
2017-08-22 в 16:52, admin, рубрики: memory management, python, Анализ и проектирование систем, Блог компании Mail.Ru Group, высокая производительность, никто не читает теги, Проектирование и рефакторинг
Одна из главных проблем при написании крупных (относительно) программ на Python — минимизация потребления памяти. Однако управлять памятью здесь легко — если вас вообще это волнует. Память в Python выделяется прозрачно, управление объектами происходит с помощью системы счётчиков ссылок (reference count), и память высвобождается, когда счётчик падает до нуля. В теории всё прекрасно. А на практике вам нужно знать несколько вещей об управлении памятью в Python, чтобы ваши программы эффективно её использовали. Первая вещь, надо хорошо в ней разбираться: размеры основных объектов в Python. И вторая вещь: как устроено управление «под капотом» языка.
Начнём с размеров объектов. В Python есть много примитивных типов данных: целые числа (int), long (версия int с неограниченной точностью), числа с плавающей запятой (они же числа с двойной точностью, double), кортежи (tuple), строковые значения, списки, словари и классы.
Plasma-протокол для чайников
2017-08-22 в 8:03, admin, рубрики: blockchain, open source, plasma, Анализ и проектирование систем, блокчейн, блокчейн технологии, высокая производительность, плазма, платежные системыРазогнаться до миллиарда: возможности и препятствия. Ведущий программист компании BankEx Александр Власов комментирует протокол Plasma, совместной разработки Lightning Network и Виталия Бутерина.
***Disclaimer*** Данное описание является попыткой описать принципы, предложенные авторами, простыми словами. Оно нисколько не отражает сложные последовательности действий и мотиваций игроков, которые должны быть проанализированы специалистами теории игр. Также, на данный момент описание находится в стадии work in progress, имеет значительные ошибки и во многом является не полным.
Несколько дней назад Joseph Poon (основатель Lightning Network) и Виталий Бутерин (основатель криптовалюты Ethereum) представили первый черновик описания протокола Plasma, призванного значительно увеличить пропускную способность блокчейн-сетей, до величин порядка миллиардов операций в секунду, по словам самих авторов.
Читать полностью »
Следущие шаги в черной магии процессоростроения после того, как вы освоили Харрис & Харрис
2017-08-22 в 7:44, admin, рубрики: asic, fpga, fpga/asic, mips, MIPSfpga, schoolmips, Verilog, vhdl, Анализ и проектирование систем, ассемблер, вшэ, высокая производительность, мгу, микроэлектроника, МИФИ, МИЭМ, нгту, программирование микроконтроллеров, Профессиональная литератураНедавно вышло еще одно печатное издание книжки Харрис & Харрис на русском языке. Это широкоохватывающий ликбез про то, как проектируют микросхемы в компаниях типа Apple и Intel (методология проектирования на уровне регистровых передач с использованием языков описания аппаратуры). До этого печатного издания вышло бесплатное электронное издание этой же книжки, которое стало вирусным — его скачивания дважды завалили британский сайт Imagination Technologies, а посты о книжке на Хабре и Гиктаймс собрали более 300,000 просмотров (1, 2, 3, 4, 5 ). История перевода книжки на русский тоже довольно поучительна — он начался как общественный проект группы энтузиастов: преподавателей российских и украинских университетов, а также русских сотрудников компаний как в Silicon Valley (MIPS, AMD, Synopsys, Apple, NVidia ...) так и в России (НИИСИ, МЦСТ, Модуль ...). Когда вышло первое печатное издание на русском языке, его тоже довольно быстро раскупили и пожаловались, что оно черно-белое. Поэтому следующий принт был цветной, улучшенного качества.
Теперь возникает вопрос: ну хорошо, вы приобрели или скачали бесплатно книжку, поняли основы цифровой схемотехники, языков описания аппаратуры Verilog и VHDL, приобрели вкус писания на ассемблере и разобрались с организацией простейшего конвейерного микропроцессора, а также как все это стыкуется с периферийными устройствами и встроенным программированием. Что делать дальше?
На снимке — Татьяна Волкова, сотрудница образовательных программ компании Samsung в Московском Физико-Техническом Институте
Читать полностью »
Разработка CPA-платформы для телеком-оператора
2017-08-22 в 7:20, admin, рубрики: cpa, Анализ и проектирование систем, архитектура системы, Блог компании Инфосистемы Джет
Под катом — рассказ о том, как мы реализовали модульную архитектуру CPA-платформы (Content Provider Access) для телеком-оператора на Fuse Fabric. Заодно объясним, почему приняли такое решение, а не стали использовать стандартный стек технологий J2EE для создания монолитного приложения.
Читать полностью »
Скажи «нет» монолитности: как мы делали CPA-платформу
2017-08-22 в 7:20, admin, рубрики: cpa, Анализ и проектирование систем, архитектура системы, Блог компании Инфосистемы Джет
Под катом — рассказ о том, как мы реализовали модульную архитектуру CPA-платформы (Content Provider Access) для телеком-оператора на Fuse Fabric. Заодно объясним, почему приняли такое решение, а не стали использовать стандартный стек технологий J2EE для создания монолитного приложения.
Читать полностью »
Борьба с хардкодами при помощи статических анализаторов С#
2017-08-22 в 7:11, admin, рубрики: .net, C#, roslyn, Анализ и проектирование систем, Программирование, Совершенный код, статический анализ кодаВ этой статье я расскажу, как мы написали собственные анализаторы кода и чистим с их помощью нашу кодовую базу .net от наиболее острых / частых косяков. Главный посыл — сделать это довольно просто, не бойтесь писать свои анализаторы для борьбы с именно вашими багами. Вторичный посыл — попробуйте наши анализаторы и сообщите о результатах. Полное руководство я писать не буду, их довольно много в интернете, а вот небольшой обзор, что это как и с какими проблемами я столкнулся, надеюсь, окажется вам полезным.
Читать полностью »
XBRL: просто о сложном − Глава 6. Погружение в XBRL − Часть 3. Вычисления и валидация
2017-08-22 в 6:50, admin, рубрики: IT-стандарты, xbrl, Анализ и проектирование систем, отчетность, стандарты, финансы, цб рф6.3. Вычисления и валидация
Теперь, когда у нас есть таксономия, позволяющая построить неплохой отчет, настало время приступить к решению ещё одного вопроса – валидация.
Как вы помните, в нашей компании работает один ‘одаренный’ математик. Несмотря на то, что отчет в целом выглядит хорошо, 27 мужчин и 15 женщин никак не могут дать общее количество сотрудников, равное 41.
К счастью, в XBRL есть решение на такой случай – базы ссылок вычислений (calculation linkbases).
6.3.1. Схема таксономии
Нам нужно внести несколько изменений в схему таксономии, чтобы начать использовать базу ссылок вычислений:
- Определить связь с базой ссылок;
- Разрешить использование необходимых ролей.
О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 3
2017-08-21 в 7:13, admin, рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, проектирование по, Промышленное программирование, разработка по, Тестирование IT-систем, тестирование по, управление проектами, формирование требований, функциональное программированиеС частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке
Использование спецификаций требований в управлении проектом
Во вступительной части была упомянута группа участников проекта, для которой мы так же обещали облегчить жизнь и обеспечить условия для эффективного использования требований – это менеджеры проекта. Что получают эти глубокоуважаемые люди при выборе предлагаемого в статье подхода?
Планируя работы по таким детальным спецификациям, еще на ранних стадиях, можно с высокой точностью определить ресурсы и сроки, необходимые для их реализации. Время, которое необходимо затратить на создание Таблицы, Формы, Функции, Отчета и т.д. можно просчитать на примере одного проекта и в дальнейшем использовать эти данные как эталонные. А в наших спецификациях, как раз и перечислены все таблицы, формы, процедуры и т.д. и сосчитать их количество не составляет труда.
Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человекоднях или человекочасах (как Вам удобнее) по подсистемам и проекту в целом.
Читать полностью »
О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 2
2017-08-19 в 10:50, admin, рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, Промышленное программирование, разработка программного обеспечения, Тестирование IT-систем, требования, управление проектами, формирование требований, функциональное программированиеС частью 1 можно ознакомиться, перейдя по ссылке
Рекомендации по проектированию спецификаций требований с примерами
То, о чем не говорят, каждый понимает по-своему
Как и было анонсировано в предыдущих разделах, мы постараемся преобразовать требования на разработку ПО в такой формат, чтобы они максимально упростили и ускорили работу команды превращающую их в конечный продукт.
Готовим читателей к знакомству со спецификациями
Итак, с чего может начинаться знакомство команды разработки, с представленными требованиями? Непременно с презентации аналитиком своего творения, будущим исполнителям. Для обоих сторон очень важно, насколько успешно будет установлен первый контакт и преодолен барьер вхождения в новый процесс. Но часто, по ряду причин очно это сделать невозможно или проблематично. Поэтому хорошим тоном будет включение в начало документа раздела, с кратким обзором его структуры и представления информации, а также разъяснением, как правильно и эффективно ее использовать.
Пример обзора документа:
Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
Читать полностью »