пятница, 10 февраля 2017 г.

И снова Creq

Создав несколько документов требований в Minireq, и поработав близко с гибкой командой разработки в течении 9 месяцев, пришел к выводу, что
  • зря обвесил его дополнительным DSL, т.к. потребности его использования не было.
  • вопрос с публикацией не актуален, т.к. GitLab отлично понимает Markdown.
  • вопрос с трассировкой не был востребован, соответственно до рабочего инструмента доведен не был.
Поэтому в один прекрасный момент, я решил все это из Minireq убрать. Но вместо уборки, потратил пару недель и упростив код, заменил новым инструментом Creq. Фактически, это Minireq без DSL.

FPA и PERT DSL были вынесены в отдельный проект SeeCalc.

Дальше буду продолжать в сторону трассировки, но уже в рамках промо-проекта.

Вообще, кажется что подход Minireq/Creq для управления требованиями сработал, сам использую :)

вторник, 29 ноября 2016 г.

SPI, API и ORM

Немногим более полу года работаю как владелец продукта. На примере двух относительно простых проектов SPI (Angular) плюс API (Java, Spring, Hibernate...) заметил интересную штуку - во втором проекте команда разработки сразу выбрала Hibernate, хотя и сталкивалась с проблемами и ограничениями в предыдущем проекте. Проблемы возникают в половине случаев, как только задача отходит от стандартной функциональности типа CRUD.

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

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

-- группировка
select month(sold_at), count(id)
from (
  -- исходный запрос по продажам
  select id, sold_at, machine_id, item_id, item_name
     from sales s join items i on i.id = s.item_id)
group by 1, 2
order by 1 DESC

Вторым примером, сейчас команда разрабатывает общий механизм для серверной фильтрации, сортировки и постраничной выдаче (есть таблица на фронте, которая умеет все это делать). Задача также прямо ложится в SQL - простое дописывание where, order by, limit, skip. Но для каждого элемента свой объектный механизм :)


Как-то в целях самообразования, на примере простой мастер-детали я сделал две версии API (ruby + grape + sequel) первую просто через SQL, вторую через Sequel::Model. Для простых моделей выигрыш минимальный - можно вполне обосновано забить на модели и оставаться в известной 30 лет логике SQL. Можно рассматривать ОРМ только если много вложенных моделей или сложная объектная логика. Например, для различных отчетов ОРМ не нужен и скорее вреден.

Sequel прекрасен тем что предоставляет оба подхода в одной коробке. На будущее, если возникнет задача. буду делать на SQL, и только по мере усложения переходить к моделям.

понедельник, 20 июня 2016 г.

Minireq 0.1.3 и Minireq-gitbook 0.1.2

Найти время на проект все сложнее и сложнее. Но за последние пару дней удалось подчистить различные досадные недоразумения и выложить новые версии.

Minireq наконец научился делать из макросов [[requirement_id]] нормальные кросс-ссылки внутри документа а также определился с каталогом ресурсов. При создании / инициализации проекта создается каталог docs/assest в который складываются изображения и другие ресурсы. В текстах требований пишу ссылки через assests/resource - локально их не видно, но после сборки docs/requirements.md все встает на свои места. Начал было преобразовывать ссылки при сборке документа, но потом бросил.

Minireq-gitbook научился делать правильные ссылки на комбинацию ASCII (requirement id) и русского текста в заголовках. Также добавлена команда deploy, которая извлекает данные из репозитория, делает книгу и разворачивает на веб-сервере.

Немного побаловался с Git Hooks (это было довольно весело потанцевать на винде сразу с node js, ruby, git sh и Go) и сейчас выглядит процесс примерно так:
  1. Commit и Push в удаленный репозиторий.
  2. Git Hook вытягивает данные, строит и разворачивает книгу в сети.
Если проектов несколько, каждый проект нужно разворачивать на разных port и live reload port.

Сейчас собираюсь сделать АПИ для комментариев и возможно в ближайшее время появится плагин для комментирования.

Когда дойдут руки постараюсь вынести PERT и FPA в отдельные плагины. Они достаточно интересны сами по себе. Спасибо Роману за Gogs :)