Reusing existing work with a stack change

[Cleop]

The existing (non native) work on Time uses Node which is no longer part of our stack: https://github.com/dwyl/technology-stack

How do we intend to make use of the existing work on Time with our new stack?

[nelsonic]

@Cleop another good question! 👍 (you're on form!) 🎉
Our reasoning for moving away from Node.js is summarised in this issue: dwyl/learn-elixir#102
It's a painful in the short-term but prudent in the long-term decision that will pay off well in time.

As discussed in dwyl/technology-stack#67 we need to extend our "PETE" stack to make it "append-only" so that we can enable an "undo" and "audit trail" functionality in all of the Apps we will be building (starting with "Time"). The work to make Phoenix append-only is "on-going". Once CID is complete we will need to integrate it into our Example: https://github.com/dwyl/phoenix-ecto-append-only-log-example and then add it to Alog (which will need to be re-worked to make the log "generic" ... tbd.)

My gut instinct is that none of the Node.js work in the current master of this repo is re-useable.
It can be worth reading for reference (e.g: for understanding the basic functionality).
But a more effective way of determining the basic functionality is our UX Research project dwyl/product-ux-research#34

[Cleop]

Makes sense to me!

[nelsonic]

Far more important than the work in this repo (which I did most of and therefore have the most to "lose" by scrapping it...) is the experience you (and the rest of the team) have gained in using the "PETE" stack over the last couple of years. You/we will be able to craft much better UI/UX in 2019 than I did in 2015; I'm confident of that. Focus on documenting how to Wireframe and do UX testing for the next week, it's an investment we must make up-front to ensure that we have a rock-solid way of testing our UX against our "OMTM" dwyl/hq#212 whenever we release a new feature. 🚀