пятница, 16 августа 2019 г.

Json in python

Долго не могла понять, что не так со словарем вида на экране
{"a":5}
Потом оказалось, что 5 - это не int, а int32. А этот тип библиотека json отказывается преобразовывать. А numpy, из которой данные-то и берутся, пишет либо float, либо int32.
Пришлось возле каждого посчитано значения вписывать float(counted_var). И преобразование в json больше не выбрасывает исключения.

пятница, 8 июня 2018 г.

С#/С++

Вспоминаю с#. Веду протокол изменений, разностей и вообще того, что удивило и порадовало.
Разница с с++:
Это предопределённых порядок выполнения операндов слева направо. В с++ такого сейчас нет, компилятор может оптимизировать все очень странно(про порядок вычисления операндов, вроде это так).

Разница между && и &. & не сокращают вычисления, && сокращают. С++ компилятор может действовать как хочет. Страуструп пишет, что вычисления с++ всегда сокращенные. Сейчас в статьях встречала, что порядок вычисления условий в заголовке условного оператора не определён, те зависит от компилятора, в с# всегда слева направо).

В плане математики в с# все более строго. Неявные преобразования с потерей информации запрещены .

Ну, сборщик мусора. Лафа и халява.

Жёсткие различия между struct и class. К этому нужно будет привыкнуть.

Область видимости переменной - это целый блок программы, где она описана, а не только блок, начиная с места непосредственного объявления. Тоже кажется нелогичным, но это так.

В с# мажно сделать псевдонимы для имён библиотек .

Можно импортировать не только пространство имён, но лишь отдельный тип (видимо тоже удобно для разрешения конфликтов имён).

Что такое out в списке типов аргументов функции - пока не дошла, только встретила использование.

Метод сжатый до выражения- это вещь для таких лентяев как я. Писать => проще чем кучу всего обычного. ; в конце метода нужна.

С конструкторами с параметрами по умолчанию надо быть осторожнее. Т.к. при изменении количества параметров всё нужно перекомпилировать. Если нет такой возможности нужно иметь варианты для обратной совместимости.

Короткий инициализатор свойств - круто

Разный уровень доступа к свойствам.

Интересный вариант для совместной работы - это  partial class. Особенно важно, что в каждой части могут быть объявлены свои интерфейсы для реализации и можно друг другу не мешать.

На сегодня все.

пятница, 1 июня 2018 г.

Как найти русскую запятую? Переход с винды на мак.

Переходить с винды на мак плохо. Особенно плохо делать это посреди рабочего процесса. Все горячие клавиши другие, приходится переучиваться. Каждый раз при Ctrl+c Ctrl+v ничего не срабатывает. Сначала залипаешь, тупишь. Потом вспоминаешь, что это мак, ругаешься и перенажимаешь command+c command+v. Я думала, что самое сложное это запомнить переключение раскладки: Ctrl+space. Но оказалось, что это цветочки.

Я долго не понимала, как найти нужные функции программ, которые на винде вызывались правой кнопкой. В мак-мыши кнока всего одна.  Те действия, те меню, что раньше показывались по правому щелчку - есть ли они вообще здесь? Или их нет и не будет? Или они должны включаться по-другому? А если  должны включаться, то как? Два дня работы я мучалась. При поиске в браузере не могла открыть ссылку в новой вкладке. Не могла добавить файл в проект на вижл студии. Не могла добавить пакет нугет. Думала, что студия под мак поэтому и называется страшно урезанной. На третий день случайно открыла, что аналогом правой кнопки мыши тут является комбинация Ctrl+mouseclick. Работать стало легче. Но те вещи, что раньше делались одной рукой, стали требовать участия двух (чай стало пить неудобно, а т.к. напитки спасают глаза от переутомления, это серьёзный минус).

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

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

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

понедельник, 25 апреля 2016 г.

Столкновения в Bullet Physics

Мне необходимо найти точки удара твердого(btRigidBody) и мягкого(btSoftBody) тела.
BulletPhysisc.org объясняет, каким образом в движке реализован поиск столкновений. Для
того, чтобы найти столкновения между двумя телами, необходимо просмотреть все
столкновения, происходящие внутри dynamics_world. Это должно быть сделано в течение
текущего тика моделирования, т.к. контакты столкновения должны быть добавлены и
удалены в течение нескольких подтактов одного такта моделирования. При контакте
объектов можно получить программную обратную связь с помощью группы функций Contact
Callback.


ContactAddedCallback вызывается когда контакт добавлен к просмотру(заметьте, что один и
тот же контакт может быть добавлен много раз, прежде чем будет обработан). Внутри
реализации ContactAddedCallback можно модифицировать некоторые свойства тел(например,
трение) в точке соприкосновения. Заметьте, ContactAddedCallback не появляется в работе при
использовании многопоточных вычислений. Форма определения:

typedef bool (*ContactAddedCallback)(btManifoldPoint& cp, const btCollisionObjectWrapper*
colObj0Wrap,int partId0,int index0,const btCollisionObjectWrapper* colObj1Wrap,int partId0,int index1);

где cp  точки соприкосновения;
colObj0Wrap, colObj1Wrap  ссылки на взаимодействующие объекты;
partId0, partId0, index0, index1  какието индексы.


Для того, чтобы выходное значение правильно обрабатывалось, необходимо возвращать
false, если не было расчитано трение. Для использования этого обратного вызова нужно
подсоединить файл btManifoldResult.h.

ContactProcessedCallback вызывается неизменно после того, как столкновение начнет
обрабатываться.
typedef bool (*ContactProcessedCallback)(btManifoldPoint& cp,void* body0,void* body1);
cp  точка соприкосновения;
body0,body1  указатели на объекты столкновения (можно привести к btCollisionObject*).
ContactDestroyedCallback вызывается при аннулировании точки контакта.
typedef bool (*ContactDestroyedCallback)(void* userPersistentData);
Эти вызовы требуют подключения btPersistentManifold.h


Также есть btNearCallback, который дает объект типа btCollisionDispatcher.
typedef void (*btNearCallback)(btBroadphasePair& collisionPair, btCollisionDispatcher& dispatcher, const btDispatcherInfo& dispatchInfo);

где btNearCallback  тип функции обратного вызова;
collisionPair  это объект класса btBroadphasePair, который содержит ссылки на
взаимодействующие объекты и на алгоритм, описывающий их взаимодействие.
dispatcher  это объект класса btCollisionDispatcher, который содерижт указатели на возможные
алгоритмы обсчета столкновений, и, самое главное, в этом классе содержаться точки
столкновения и глубина взаимного прониковения объектов.
dispatchInfo  это объект класса btDispatcherInfo, который содержит вспомогательную
информацию.

Определение вызова находится в файле btCollisionDispatcher.h, для того, чтобы переопределить этот обратный вызов необходимо подключить данный заголовок. Я переопределила у себя ContactAddedCallback, и остальные обратные вызовы этой группы, но они не вызывались при контакте твердого и мягкого тела.

Обратный вызов btNearCallback вызывался при контакте твердого и мягкого тела, но точки  контакта оставались неизвестны.

Для твердых тел и ContactAddedCallback и btNearCallback работали замечательно.
Оказалось, что в алгоритме расчета столкновений твердых и мягких тел функция расчета
точек столкновения еще нереализована.


Итак, сейчас дела обстоят так, что обратный вызов при контакте двух тел(мягкого и
твердого) есть, видимое взаимодействие есть, но точки взаимодействия не записываются в
поле btAlignedObjectArray<btPersistentManifold*> m_manifoldsPtr и время столкновения тоже не расчитывается.


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

среда, 6 апреля 2016 г.

Описание классов Collision Shapes

Отсюда. Отрывки. https://www.raywenderlich.com/53077/bullet-physics-tutorial-getting-started
Масса(mass). Масса - это очевидно масса объекта, но у нее есть другое, не так очевидное обозначение. В Bullet вы можете создать три типа объектов, разница в которых определяется их массой.
1. Масса статического объекта нулевая (mass = 0). Такой объект неподвижен. В игре, например, это граница.
2. Масса кинематического объекта также нулевая, но вы можете двигать это объект в коде, просто устанавливая его позицию и поворот. Объекты мира при моделировании не смогут его сдвинуть. В игре, например, это весло и кирпич.
3. Масса динамического объекта ненулевая. Вы двигаете объект при помощи приложения к нему силы. В игре, например, это мяч. Вы устанавливаете его направление и скорость и включаете физический движок. Когда мяч ударяется о границу или о кирпич, он будет отскакивать назад, но он никогда не изменит позицию границы, кирпича или весла, т.к. они неподвижны.

Выпуклый(convex) - это флаг, описывающий является ли текущий физический объект выпуклым или вогнутым. Необходимо всегда пытаться использовать выпуклые объекты, т.к. физический движок работает намного быстрее с ними. Можно разбить вогнутый объект на несколько выпуклых объектов. С момента создания вогнутых объектов нужно ставить флаг, т.к. работа движка будет отличаться.

Вы используете тег (tag) в обнаружения столкновений, чтобы определить, какие типы объектов столкнулись.

shape описывает форму физического тела. btCollisionShape является абстрактным классом, и есть несколько разных реализаций столкновения фигур. Например, можно описать форму объекта в виде сферы, используя btSphereShape или вы можете создать сложные формы с btBvhTriangleMeshShape указанием вершин треугольников, так же как при визуализации сложных объектов в OpenGL.

Создать корпус объекта можно с помощью готовых классов создания сфер, кубов(btBoxShape), btPolyhedralConvexShape() (многогранник), а можно задать по точкам (btConvexHullShape()).

Список классов создания корпуса объекта.

Классы создания корпуса объекта. 
btBox2dShape - это примитив квадрата вокруг начала координат, его оси сторон связаны с длиной, определенной полуразмерами в локальной системе координат. Когда используется как часть btCollisionObject or btRigidBody, это будет ориентированный квадрат в пространстве. Его размеры по оси Z = 0.

btBoxShape - это примитив куба вокруг начала координат, его оси сторон связаны с длиной, определенной полуразмерами в локальной системе координат. Когда используется как часть btCollisionObject or btRigidBody, это будет ориентированный куб в пространстве.

btBvhTriangleMeshShape - является фигурой из сетки статически-треугольной(static-triangle mesh shape), она может быть использована только для стационарных/недвижущихся объектов. Если требуется перемещение вогнутой сетки, рекомендуется выполнять выпуклую декомпозицию используя HACD, смотри Bullet/Demos/ConvexDecompositionDemo. Кроме того, вы можете использовать btGimpactMeshShape для перемещения вогнутой треугольной сетки. btBvhTriangleMeshShape имеет несколько оптимизаций, таких как иерархия ограничивающих объемов(bounding volume hierarchy) и кэш-фрэндли обход для PlayStation 3 ячейки СПУ(cache friendly traversal for PlayStation 3 Cell SPU). Рекомендуется включить useQuantizedAabbCompression для лучшего использования памяти. Принимают треугольные сетки в качестве входных данных, например btTriangleMesh или btTriangleIndexVertexArray. Класс btBvhTriangleMeshShape позволяет деформации сети с помощью метода refit или partialRefit. Вместо построения (the bounding volume hierarchy acceleration structure) структуры, также можно сериализовать (сохранить) и десериализировать(загрузить) структуры с диска. См. Demos\ConcaveDemo\ConcavePhysicsDemo.cpp для примера.

btCapsuleShape - представляет собой оболочку вокруг оси Y, (существует так же btCapsuleShapeX, выровненный вокруг оси X и btCapsuleShapeZ вокруг оси Z). Общая высота фигуры это height+2*radius, поэтому height - это только расстояние между центром каждой сферы на концах оболочки.
В btCapsuleShape является выпуклой оболочкой двух шаров. А btMultiSphereShape-это более общая форма столкновения, которая принимает выпуклую оболочку множественных сфере, поэтому она также может представлять собой капсулу, если задать только две сферы.

btCompoundShape позволяет хранить несколько других btCollisionShapes. Это позволяет двигать вогнутые объекты столкновения. Это более общие, чем статическая вогнутая сеть btBvhTriangleMeshShape. Он имеет (опционально) динамическое аавв дерево, чтобы ускорить тесты раннего отказа. В настоящее время удаление дочерних фигур поддерживается только при отключении опции аавв дерева (передать значение 'false в конструкторе btCompoundShape).

Класс btConcaveShape предоставляет интерфейс для неподвижных (статических) объектов вогнутой формы. Его реализуют btStaticPlaneShape, btBvhTriangleMeshShape и btHeightfieldTerrainShape.

btConeShape реализует примитивную форму конуса с центром в начале координат и на оси Y. Класс btConeShapeX выравнивается по оси X и btConeShapeZ вокруг оси Z.

btConvex2dShape позволяет использовать произвольные выпуклые фигуры как 2D выпуклой формы, где компонент Z полагается равным 0. Рекомендуется для btBox2dShape .

btConvexHullShape реализует создание неявный выпуклой оболочки из массива вершин.
Bullet предоставляет общие и быстрый детектор столкновений для выпуклых форм на основе GJK и EPA, используя localGetSupportingVertex.

btConvexTriangleMeshShape является выпуклой оболочки на основе треугольной сетки, но производительность не так хороша, как у btConvexHullShape. Малое преимущество этого класса в том, что он использует btStridingMeshInterface, так что вы можете избежать дублирования данных триангулированной сетки. Тем не менее, большинство пользователей должны использовать гораздо более производительный btConvexHullShape.

Класс btCylinderShape реализует примитивные формы цилиндра, с центром в начале координат. Его Центральная ось совмещена с осью у. btCylinderShapeX совмещена с осью X и btCylinderShapeZ вокруг оси Z.

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

воскресенье, 14 сентября 2014 г.

Заморочки или как работать когда не работается.

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

пятница, 5 сентября 2014 г.

Qt, пока все еще qt.

Бьюсь с qt creator за правильное расположение виджетов. Бой неравный. В первом раунде, при расположении horizontal layout, я выйграла. Все отображается как надо. Но победа оказалась добыта только после такого финта ушами, что ужас просто. Чтобы компоновщик заработал, его обязательно нужно включить через меню вызова компоновщика, при выделении нескольких объектов для компоновки. При том, что в дизайнере есть объект компоновщика на панели для перетаскивания. Но если просто его перетащить, то работать почему-то не будет. Ужас. Настроить компонтвщик для своих самодельных виджетов у меня пока так и не вышло. Они выравниваются вручную. Хорошо что я догадалась их поместить на одну панель. Панель из стандартных виджетов, поэтому она компоновщику подвластна.  Еще одна непонятная вещь -как вручную править horizontal header элемента table view. Примеры из интернета не хотят компилироваться. Он редактируется только через дизайнер. Так что, вопросов к qt пока намного больше, чем ответов.

вторник, 5 августа 2014 г.

Имитационное моделирование

Имитационное моделирование - именно так называется то, чем я на работе занимаюсь. Но до сего момента я довольно слабо представляла, что это такое. Но сейчас меняются некоторые обстоятельства, и не вполне понимать задачи по работе стало невозможно. Я пыталась найти что-то по моделированию, чтобы узнать, что это такое. Но находила узкоспециальные книги, к тому же совершенно не подходившие мне по рассмотренным темам. Например, целая книга о теории очередей. Очень интересно, но это мне сейчас пока не надо и поэтому  неинтересно! Я только недавно прочитала "Моделирование систем"   Советова и Яковлева. И порадовалась, что все-таки нашла эту книгу и что что-то мне стало понятно и более-менее все  разобралось по  полочкам. Оказалось, что и очереди, и ТАУ, и стохастические системы, которыми нас в институте мучили - все это разные модели представления реального объекта. Выбираешь, какие аспекты объекта тебе важны, подбираешь подходящую модель под эти аспекты, моделируешь - и можешь смотреть результаты. Самое прикольное, но мне кажется, это часто бывает, книгу Советова легко читать. А лекции по имитационному моделированию, которые я пыталась читать раньше, но не получалось, можно и забросить. Потому что те варианты, что у меня есть, они - список, и не очень хороший, - с этой  книги. Так что я рада, что прочитала, но немного расстроена, что так поздно ее нашла.

вторник, 10 июня 2014 г.

Как изучать чужой код

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

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

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

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

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

Итак, здесь есть несколько способов-отмычек, чтобы чужой код стал яснее. Я, как всегда, пишу статью  как будущего помощника себе самой. Может быть, и вам поможет применение данных методов. Может быть, что все эти методы не помогут. Видимо, в этом случае придется писать все с нуля. Кстати, это тоже метод изучения программ:). Желаю удачи!

пятница, 16 мая 2014 г.

Что такое HLA?

Я вышла на работу и там сейчас проект, на основе OpenRTI. Я пыталась как-то понять, что это, но сразу не получилось. Сегодня нашла общее описание. Это курсовая какого-то немецкого студента. В ней объясняется немного, что такое HLA, RTI и для чего они нужны. Но, т.к. статья на английском, я ее перевела и сюда напишу. Перевод - не точный. Я все-таки программист, а не переводчик.

Что такое HLA

HLA (High Level Architecture, архитектура высокого уровня) - это архитектура для моделирования и имитирования. Используя HLA компьютерные модели могут взаимодействовать (т.е. обмениваться данными и синхронизировать действия) с другими компьютерами, не смотря на различие платформ. Взаимодействия между моделями управляеся RTI (Run-Time Infrastructure Инфрастструктура среды исполнения?).

HLA - это стандарт возможности взаимодействия для распределенных моделей, применяемый для поддержки ананлиза, разработки и управления,  тренировки в некоторых областях, как:
  • средства обороны;
  • управление воздушным транспортом;
  • здравоохранение.

Она разработана под стандартом IEEE1516.
 IEEE 1516-2010 - Стандарт архитектуры высокого уровня для моделирования и имитации  - структура и правила.
IEEE 1516.1-2010 -Стандарт архитектуры высокого уровня для моделирования и имитации  - спецификации федерального интерфейса (сервера).
  IEEE 1516.2-2010 - Стандарт архитектуры высокого уровня для моделирования и имитации  - спецификация шаблона объектной модели.
IEEE 1516.3 - 2003 Рекомендуемая практика разработки HLA федерации и процесс использования.
IEEE 1516.4-2007- Рекомендуемая практика для проверки, валидации и аккредитации федерации как надстройка над разработкой HLA федераций и процессом использования.

Технический обзор

HLA состоит из следующих компонентов:
  • Cпецификация интерфейса(Interface specification): определяет, как HLA совместимые модел взаимодействуют с RTI, предоставляющим библиотеку и api (прикладной программный интерфейс) совместимый с интерфейсной спецификацией.
  • Шаблон объектной модели(Object Model Template): определяет какая информация взаимодействует между моделями и как она документируется.
  • Правила(Rules). Модель жестко подчиняется, для того, чтобы соответствовать стандарту.
  • Федерат(Federate). Сущность, единица модели, совместмая с HLA.
  • Федерация(Federation) - множество моделируемых сущностей, соединяющихся с помощью RTI, используя  шаблон объектной модели(OMT).
  •  Объект(Object)  - набор связанных посылок данных между моделями (? тактами моделирования).
  • Атрибут (Attribute) - поле данных объекта.
  • Взаимодействие(Interaction) - действие, посланное между модельными сущностями.
  • Параметр(Parameter) - поле данных или взаимодействие.

Спецификация интерфейса.

Спецификация интерфейса объектно-ориентированно в соответствии с техническими условиями С++ или Java. Она разделена на группы:
  • Управление федерациями.
  • Управление объявлениями.
  • Управление объектами.
  • Управление имуществом(ownership).
  • Управление временем.
  • Управление распределением данных.
  • Сервисы поддержки.

Шаблон объектной модели.

Шаблон объектной модели представляет собой общую структуру для коммуникации между HLA моделями. Он зависит от следующих документов:
  • объектная модель федерации(FOM);
  • объектная модель одного федерата(SOM).

Правила.

Правила описывают обязанности федерации и присоединенных федератов.
  1. Федерации должны иметь HLA FOM, документированную в соответствии с HLA шаблоном объектной модели.
  2. В федерации все представления об объектах в FOM должны быть в федератах, а не в инфраструктуре (RTI).
  3. В течение работы федерации все обмены данными между федератами должны проходить с помощью RTI.
  4. В течение работы федерации, федераты должны взаимодействовать с RTI в соответствии со спецификацией интерфейсов HLA/
  5. В течение работы федерации атрибуты текущего состояния объекта должны принадлежать только одному федерату в любой момент времени ( не поняла точно этот пункт, поэтому привожу оригинал:During a federation execution, an attribute of an instance of an object shall be owned by only one federate at any given time.)
  6. Федераты должны иметь HLA SOM, документированную в соответствии с HLA OMT.
  7. Федераты должны быть способны обновлять и/или отражать любые атрибуты объектов в их SOM и посылать и/или получать SOM взаимодействие извне, как установлено в их SOM.
  8. Федераты должны быть способны передавать и/или принимать имущество (ownership) атрибута динамически в течение работы федерации, как установлено в их SOM.
  9. Федераты должны быть способны изменить условия, под которыми они осуществляют обновления атрибутов объектов, как установлено в их SOM.
  10. Федераты должны быть способны управлять локальным временем способом, который позволит им координировать обмен данными между федератами.

OpenRTI

OpenRTI это реализация RTI c открытым исходным кодом. Эта реализация представляет следующие три версии RTI:
RTI13 - HLA версия 1.3
RTI1516 - первый HLA стандарт версии 1516
RTI1516e - HLA стандарт 1516-2010


Итак, перевод закончен.
Из ближайших планов на работу: мне необходимо изучить интерфейс RTI1516, т.к. он используется. Ура. Это только одна папка из трех. Хоть чуть понятнее стало.

четверг, 8 мая 2014 г.

Качество ПО, часть 2.

Разные методики тестирования и проверок находят ошибки на разных этапах. Те, ошибки, что были раньше выявлены, обходятся дешевле в исправлении. Т.о. инспекции кода обходятся дешевле тестирования. Методика способствующая раннему обнаружению ошибок снижает стоимость их исправления.
Эффективная программа контроля качества включает комбинацию методик проверки, применяемые на всех этапах разработки. Макконнелл предлагает следующую комбинацию методик, для достижения высокого качества ПО:
  • формальные инспекции требований, аспектов архтектуры, всех проектов критических частей системы;
  • моделирование или прототипирование;
  • чтение или инспекции кода;
  • тестирование выполнения программ.
Главный закон контроля качества ПО - повышение качества системы снижает расходы на ее разработку.
Лучшим способом повысить производительность труда программистов является минимизация времени, затрачиваемого на исправление кода.

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

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

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

понедельник, 5 мая 2014 г.

Качество По

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

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

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

Одна из эффективных методик повышения качества ПО - явное определение целевых внешних и внутренних характеристик. Контроль качества должен быть явным. Тестирование лишь один аспект контроля качества. Качество ПО повышается и от неформальных, и от формальных обзоров кода.

Макконелл привел таблицу эффективности обнаружения дефектов. Выводы из этой таблицы меня поразили. Я давно читала книгу про разработку через тестирование, и была уверена, что если бы могла легко протестировать автоматически визуальную часть приложения, в ней было бы меньше ошибок. Но оказалось, что блочное тестирование дает шанс выявить в среднем 30% ошибок. И что самыми хорошими результатами обладали формальные инспекции кода, моделирование, формальные инспекции проекта. По эффективности их обошло только масштабное (более чем в 1000 организаций) бета-тестирование. Вот так вот интересно.

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

Чтение кода способствует нахождению дефектов интерфейса, а функциональное тестирование - нахождению дефектов управляющих структур.  Интересно. Но эту вещь я не проверяла.

Методики поиска дефектов лучше применять в комбинации. Одни методики помогут обнаружить одни дефекты, а другие - еще некоторые.

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

четверг, 1 мая 2014 г.

Как важны мелочи 2

Программа не работала оттого, что я не написала один пробел в запросе на создание БД.
Это добавление к посту о том, как важны мелочи.

воскресенье, 30 марта 2014 г.

Как важны мелочи

Я переписывала пример из книги. Управление классом Cursor взял на себя класс CursorLoader. Он должен был создавать объект, приводимый к типу Loader<Cursor> и позволять с ним работать. Но сперва у меня выдавалась ошибка компиляции. Я довольно долго не понимала, в чем дело. CursorLoader к нужному классу не приводился. Я думала, что в книге опечатка. Пошла в интернет. Там то же самое. Решила, что скорее всего, что-то не так у меня в коде. И оказалось, что для CursorLoader я указала неправильный пакет. Т.е. я пыталась использовать совершенно другую функцию,  с другими возможностями. Поэтому невозможно было приведение типов. Итак, призываю себя к вниманию, вниманию и еще раз к вниманию. Одна ошибка найдена и исправлена! Но программа все равно пока не работает(.

пятница, 28 марта 2014 г.

SQL в андроиде

Для хранения данных между программными сессиями в андроид используется встроенная база данных. Каждое приложение может создать там свои таблицы и будет иметь к ним доступ. Для работы с БД есть классы ContentProvider, Cursor, SQLiteOpenHelper. Я до сих пор не разобралась, для чего их так много и что они делают. Я тупо переписываю пример из книги в программу и никак не соединю части в одно целое. Может,  это потому, что вообще тема баз данных для меня сложная, т.к. я ее нормально не успела прослушать в институте. Пока я зависла на них. Переписывание примера до сих пор не закончено. Получается все по странице из книги в день в лучшем случае. Хотя, может быть, это просто потому, что переписывание меня не вдохновляет. Нужно взять себя в руки и допереписать. А потом править то, что уже надумалось. И пробовать широковещательные приемники и вызовы сторонних программ из приложения. Почему-то это меня больше вдохновляет. Хотя эта тема для меня такой же темный лес, как и БД.

понедельник, 17 марта 2014 г.

Пометки для себя

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

пятница, 14 марта 2014 г.

Переопределение и перегрузка

В Java как и в C++ возможна перегрузка методов. Т.е. возможно создать методы с одинаковыми именами и с разным набором параметров, так, что выбор нужного метода определяется входными параметрами. Так же возможно переопределение родительского метода в классе-наследнике. Для переопределения необходимо, чтобы и название метода, и его параметры соответствовали классу-родителю. Иначе вместо переопределения получится перегрузка. Для того, чтобы минимизировать количество ошибок, в языке Java есть аннотация @Override. В классе-наследнике перед методом, который нужно переопределить, ставится аннотация  @Override и компилятор выдает ошибку на этапе компиляции, если вместо переопределения получается перегрузка, т.е. если параметры метода, подлежащего переопределению не соответствуют параметрам метода в родительском классе.

пятница, 7 марта 2014 г.

Конец про класс и про методы.

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

 Минимизация сложности класса:
  • Включайте в класс как можно меньше методов.
  • Неявно сгенерированные методы, которые не нужны, блокируйте.
  • Минимизируйте число разных методов, вызываемых классом.
  • Избегайте опосредованных вызовов методов из других классов.
 Несколько слов о конструкторах.
Инициализируйте по возможности все данные-члены!
Если нужен класс-одиночка - используйте синглтон.
Создавайте конструктор полного копирования, если сомневаетесь - для С++ это верно. Нужно ли это в Java, я не помню(.

Причины создания класса.
  • Моделирование объектов реального мира.
  • Моделирование абстрактных объектов.
  • Снижение сложности.
  • Изоляция сложности.
  • Сокрытие деталей реализации.
  • Ограничение влияния изменений.
  • Упрощение передачи параметров в методы - если несколько методов используют одни и те же данные, вероятно, их нужно выделить в класс.
  • Создание центральных точек управления.
  • Облегчение повторного использования кода.
  • Планирование создания семейства программ.
  • Упаковка родственных операций.
  • Выполнение специфического рода рефакторинга.

Методы.

Далее в книге идет целая глава, посвященная методам.
Причины создания методов во многом такие же, как и причины создания классов. И кроме этого, есть еще несколько:
  • снижение сложности;
  • формирование понятия промежуточной абстракции;
  • предотвращение дублирования кода;
  • поддержка наследования - т.к. переопределить небольшой грамотно спроектированный метод проще, чем длинный и плохо спроектированный;
  • сокрытие очередности действий;
  • сокрытие операций над указателями - неочевидная для меня причина, но очень разумная и приводящая к простоте написания программы;
  • улучшение портируемости;
  • упрощение сложных булевых проверок - мне раньше казалось, что наличие таких проверок - это показатель "крутости" кода, но они практически нечитаемы после написания и отладки; поэтому и с этой причиной я согласна; попытаюсь впредь делать так;
  • повышение быстродействия.
Проектирование на уровне методов - проектирование методов. Методы характеризуются связностью (или силой) - соответствием выполняемых в методе операций единой цели. Самый распространенный пример хорошего метода - операция cos() или sin(). Метод cosinAndTangens() - имеет худшую связность, т.к. выполняет сразу две операции.
Цель - чтобы один метод эффективно решал одну задачу и больше ничего не делал.

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

  • Описывайте все, что метод выполняет
  • Избегайте невыразительных и неоднозначных глаголов
  • Не используйте для различия методов исключительно номера (method1 (), method2 ()...)
  • Не ограничивайте длину имени методов искусственными правилами - имя метода длиннее имени переменной; главной задачей имени является ясное и понятное описание сути метода.
  • Для именования функции используйте описание возвращаемого значения.
  • Для именования процедуры используйте выразительный глагол ( дополняя его объектом, если язык не ОО).
  • Определяйте конвенции именования часто используемых операций.
  • Дисциплинированно используйте антонимы. Т.к. это тоже одно из моих больных мест, пишу здесь часто используемые:
add/remove
begin/end
create/destroy
first/last
get/put
get/set
increment/decrement
insert/delete
lock/unlock
min/max
next/previous
old/new
open/close
show/hide
sourse/target
start/stop
up/down

Желательно, чтобы длина метода была не более 150-200 строк(без комментариев и пустот), обычно метод занимает до 100 строк. Если метод хорошо спроектирован, он уложится в эти рамки (должен).

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

Про макросы. 
Опять же, программируя на С++ я думала, что использовать макросы - это показатель крутости. Но их использование давало иногда такие ошибищи которые очень трудно было отследить и понять.  Макконнелл не рекомендует использовать макросы, кроме как в условной компиляции (он ссылается в этом на Страуструпа, а тот, видимо, знает, что говорит)).

Итак, ура. Глава, посвященная методам обработана. Надеюсь, я буду это все использовать. Очень часто при чтении этой книги у меня возникают мысли: а, как просто-то, а я... Учиться мне еще и учиться...

суббота, 1 марта 2014 г.

Наследование. Продолжение.

Наследование. Отношение "Является".
  • Убедитесь, что вы наследуете только то, что хотите наследовать. Не наследуйте реализацию только потому, что вы наследуете интерфейс. Если интерфейс класса не нужен, а нужна лишь реализация, то лучше включение, а не наследование.
  • Не используйте имена непереопределяемых методов базового класса в производных классах.
  • Перемещайте общие интерфейсы, данные и формы поведения на как можно более высокий уровень абстракции. 
  • С подозрением относитесь к классам, объекты которых создаются в единственном экземпляре. Исключение - "Одиночка".
  • С подозрением относитесь к базовым классам, имеющим только один производный класс.
  • С подозрением относитесь к класам, которые переопределяют метод, оставляя его пустым (убирая реализацию).
  • Избегайте многоуровневых иерархий наследования.
  • Предпочитайте полиморфизм, а не крупномасштабную проверку типов.
  • Множественное наследование - "инструмент, который лучше большую часть времени хранить в гараже под замком". Может пригодится, но может и порождать ошибки (ромбовидная схема!).
Правила, чтобы понять, нужно ли проектировать классы как наследники или включения.
Если несколько классов имеют общие данные, но не формы поведения, сделайте общий объект, который включите в эти классы.
Если несколько классов имеют общие формы поведения, но не данные, сделайте эти классы производными от общего базового класса, определяющего общие методы.

вторник, 25 февраля 2014 г.

Продолжаю конспектировать "Совершенный код".
Раздел "Вопросы проектирования и реализации".
Класс может содержать данные или другой класс. Это отношение "Включение".
  1. Реализуйте с помощью включения отношения "Содержит".
  2. В самом крайнем случае такое отношение может быть реализовано с помощью закрытого наследования -  автор считает, что если получается только так, то это ошибка проектирования и что лучше всего еще раз подумать. Наверное, он прав. Я с таким на практике еще не сталкивалась.
  3. Настороженно относитесь к классам, содержащим более 7+\-2 данных-членов. Автор считает, что можно класс, содержащий много данных разбить на несколько классов, содержащих небольшое количество данных, и что это поможет упростить работу с данными. Опять же, нужно проверить на математике "Mittens".
Теперь наследование.
"Цель наследования - создать более простой код, что достигается путем определения базового класса, идентифицирующего общие элементы двух или более производных классов."
  1. Реализуйте при помощи открытого наследования отношения "является". Если производный класс не будет полностью придерживаться контракта, наследоваться не надо.
  2. Проектируйте и документируйте классы с учетом возможности наследования или запретите его.
  3. Соблюдайте LSP: клиенты должны иметь возможность использования подклассов через интерфейс базового класса, не замечая никаких различий. Если программист, сделав наследование, забывает о деталях реализации наследников - все ОК. Если он должен думать о семантических различиях реализаций подклассов - наследование зло, тк. не способствует снижению сложности. 
Продолжение следует...