Difference between revisions of "Redvant"

From Cibernética Americana
Jump to: navigation, search
(Story)
 
(31 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
<div class="plainlinks" style="background-color: maroon; color: white;">
 
<div class="plainlinks" style="background-color: maroon; color: white;">
<div style="background-color: navy;"> &nbsp; &nbsp;
+
<div style="background-color: indigo;"> <blockquote>
<div style="width='95%'; background-color: black;">
+
<br>
 +
<div style="width='95%'; background-color: grey; color: white;">
 
<blockquote>
 
<blockquote>
 
= Pr&eacute;cis =
 
= Pr&eacute;cis =
  
'''Redvant''' is react, redux, with servant backend as a focus/incubator for DCMS FE and tl:dr Jackson, elements of my systems and consumer product development, respectively.
+
'''Redvant''' is purescript-react, red FE with  
 +
[https://haskell-servant.readthedocs.io/en/stable/ <span style="color: pink;">servant</span>]
 +
backend as a focus/incubator for DCMS and tl:dr[AK] apps.
 +
<blockquote>
 +
"red" could be
 +
<blockquote>
 +
react, redux, redis, or just plain red, a simple name.
 +
</blockquote>
 +
and "vant" is just from haskell-servant.
 +
</blockquote>
 +
 
 +
Stands for otherwise unnamed consumer product development flows in my public job shop outside of the DDD process.
  
 
{{TOCright}}
 
{{TOCright}}
Line 11: Line 23:
 
= Story =
 
= Story =
  
Redvant is a name for a software development architecture/pipeline defined by main implementation elements of its endpoints.
+
Redvant is a name for a dev workflow defined by an implementation path from front end thru DCMS middleware, to arbitrary domain space function, but particularly Apache ISIS based end consumer apps such as GT2 and TASKPM.
 
 
Ideally, the layers of the mediating app between these endpoints would be developed from first DDD principles.
 
  
Practically, much prexisting functionality can be exposed thru this channel, regardless of it's origin if its function can be abstracted.
+
Ideally, the layers of any mediating app between these endpoints would be developed from first DDD principles. Practically, besides the GT2 and TASKPM exemplars, just doing it and getting it done to a useable state is the good here.
  
 
== Residue/Result ==
 
== Residue/Result ==
Line 22: Line 32:
 
#ISIS Common DS platform builds for
 
#ISIS Common DS platform builds for
 
<blockquote>
 
<blockquote>
[https://play.google.com/store/apps/details?id=org.commoditysoftware.greentravel GT2], [https://tl-drak.meansofproduction.biz/products/tl-drtask TASKPM], and [https://sameboat.live/content/services <span style="color: pink;">SB apps</span>], which have a routinized domain
+
[https://play.google.com/store/apps/details?id=org.commoditysoftware.greentravel <span style="color: pink;">GT2</span>],  
driven methodology by which [https://case64.meansofproduction.biz they move] as doamin driven jobs thru my shop.
+
[https://tl-drak.meansofproduction.biz/products/tl-drtask <span style="color: pink;">TASKPM</span>], and [https://sameboat.live/content/services <span style="color: pink;">SB apps</span>], forming DDD product line engineering flows <br>with standard timeline(s) (e.g.: [https://case64.meansofproduction.biz <span style="color: lime;">biz case 64</span>]) as domain driven job streams in the <br>[http://pm-lets.principalsonly.org Public Job Shop (PJS)].
 
</blockquote>  
 
</blockquote>  
 
#Jitsi adapted to DS
 
#Jitsi adapted to DS
Line 30: Line 40:
 
</blockquote>
 
</blockquote>
 
<br>
 
<br>
</div>
+
</blockquote>
 +
</div></blockquote>
 
<br>
 
<br>
</blockquote>
 
 
</div>
 
</div>
 
</div>
 
</div>

Latest revision as of 16:23, 12 April 2019