среда, 29 июля 2020 г.

Clerq Ruby Gem

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

В прошлом году, пристут был навеян Clear Architecture и получился  Clerq. И так мне он понравился что даже заморочился на красивое описание в github pages.



пятница, 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, и только по мере усложения переходить к моделям.