Zeljko Milinovic <zeljko.milgrz@...>
Hi to all,
I just came upon an article:
It seems so that IBM folks will no longer invest so much in Composer.
My question to all of you and especially to Ben, what are our alternatives?
Could we still use Javascript or we have to remodel and reprogram everything in Go language?
Kind Regards.
Zeljko Milinovic
toggle quoted messageShow quoted text
Hi Marissa, Thanks for the great Email. I added my suggestions in bolded text. ____________________
Responses to Zeljko and Ben's Questions
1 .We could make inside the WIKI page some Collaboration, or
maybe would be great if we could rent some JIRA Spaces for developing the
project further.
=> Agreed, a board
would be convenient to organize ourselves and help prioritize what is a P0
feature versus nice to haves. @all, do we already have a board tool available?
I have made a request with Hyperledger Help Desk to get us a
JIRA workspace where we can organize ourselves. We confirmed that logging into
this tool will be via Linux Foundation ID, so it will ensure equal access to
everyone on the projects. TBD on when we get this, but I will keep everyone
posted. Friday we had discussed using the donor milk wiki as a placeholder for
requirements and stories (see Section 2). @Mikhail Elias you had mentioned wanting to use this as a
test case for some wiki work, so let me know how I can help
Thanks Marissa. I
think to make further great progress with the PoC the JIRA workspace is of a
great esence to the project, as I mentioned already. Team cannot continue to be
agile without this tool. Wiki is ok and we can collaborate here, but the
project needs more for the troubleshootings and builds.
2. We could use Mocha and Cucumber for testing the model
before deploying
=> I've never used
Cucumber but if we have time to write some proper unit tests before the
deadline then yes, we should. I'll try to include some proper user stories we
can turn into tests sometime next week.
Ben has built a great
.CTO model that I have reviewed and commented. I have learned a lot from his
model, great work Ben. As fort he Mocha and Cucumber, we can use these tools to
test the model before we get into further application development. Those are
great frameworks for testing the model assuming that we will have a lot of data
on the chain and to simulate those situations.
My knowledge is very limited here, but I'm assuming we're
talking about setting up a test network? In speaking with Tracy, she reminded
me that all Fabric nodes do not have to be in the same cloud server, so I have
reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's
offer is generous to stand up a VPS for the group, it is not ideal. If this is
not what you're referring to here, my comments are still relevant, just not for
this topic :-).
As fort he VPS instance,
maybe we could get on from the Linux Foundation. I offered help here and also
talked to Ben about this. This is also very important, because when we start to
build the WEB and MOBILE APPs , we would need a living REST Server and also to
achieve UNIT Testing without a living VPS instance will not be possible.
3. We should check the Child-Parent Relationships
(Asset-Owner and changing of the owner in the Supply Chain) I would recommend
here the analogue to the Reversible Relationships
=> I'm using a
tree based structure where every change of state (split/pooling) triggers the
creation of a new asset ID. This isn't quite the same as RR (you can revert
back into the original asset ID) but with every node being linked to both
parent and child this allows for complete traceability.
No comment
As for the
relationships, tree based what Ben did is great, but I think when we test this
model with simulating a lot of data with Mocha or Cucumber, we could come up on
performance issues with the Mobile app, becuase every change of state creates a
new Asset ID, an I was thinking with RR we have a unique ID for one asset from
the beginning of the life cycle. But this is something to be tested in the
future with Ben. May be that I am also wrong here, cannot really tell before I
test the Model on a live network VPS.
4. Maybe we could discuss topics in JIRA about the Owner
Status of the milkAsset Asset
=> This ties back
to 1. I've also made a pull request to the original repo so we'll be able to
create tickets for these discussions.
Yes, if people want to start logging issues in GitHub now
(as we wait for JIRA), please feel free to do so in the Issues Tab of the repo.
I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to
have.
=> Absolutely, the
reason why I forked in the first place was to experiment but with the pull I'll
be documenting (see 2) so that anyone can contribute.
Yay, documentation!
@Benjamin Djidi - are we still looking for someone to engage
on the access permissions work? Markus CC'd here had mentioned he had some
resources to lend, so we can pursue that if needed. Also, would it be helpful
to speak to the Identity Working Group on this? They have offered to come and
talk to the HCWG, so was wondering if this would be along the same vein or not.
As for the
relationships, this should not be a great issue. It needs to be defined (from
the Use Case and the processess that are now in use) which participants need to
access what and it can be coded pretty fast.
Recommended approach for working with the Donor Milk code
repository
I'd love for someone to write up a quick best practices for
engaging with the milk-donor repo code. I'm not the best person to do it.
Anyone interested?
Below are all of the resources we have so far. In addition
to the below we have confirmed that only members of the milk-donor-committers
team can actually merge a pull request: currently this is Angela, Ben, and
Zeljko. Let me know if others want to be included in this group.
Here are the resources that Angela, Ry and Tracy have sent
out (Many Thanks!):
The link to the github docs that outlines and explains how
to create a pull request to add files from a fork
https://help.github.com/articles/creating-a-pull-request-from-a-fork/
Making your first pull request in Hyperledger:
https://www.youtube.com/watch?v=f5XZe7dv0_U
Here are a couple of more resources that may help:
Gist on Contributing - Tracy made this for the Training and
Education WG, but if you change out https://github.com/hyperledger/education
and references to local education repository, the general ideas should apply to
the Milk Donor lab.
git Workflow Presentation - a presentation that is basically
identical to the above Gist.
Tracy uses this workflow to sync her local fork -
https://help.github.com/articles/syncing-a-fork/. There should probably be a
step #6 which is a `git push` command to push the merged changes back to the
local fork
Update on MPV UI Workflow
I know this is far from what the person creating the UI will
need, but I tried to breakdown the high- level flow by actors and then whether
or not the system was engaged at each step. This can be found in Section 2 of
the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx
Several questions came up for me while working on this,
especially around when the donor milk application was going to be used on a
computer vs a handheld for scanning, and how scanning would actually work in
the laboratory setting. I'd like to get feedback and then take this to our SMEs
for input. Thoughts?
We could use the Bar
Code or QRCode NodeJS libraries for scanning the assets for the apps. Just a
thought.
Kind regards. Zeljko Milinovic, MSc http://itstuffallaround.blogspot.com/
Hello Everyone!
We had a great meeting on Friday, and thanks to Ben for showing us what has been built in the network so far. We will have full notes posted shortly, but I wanted to respond to a couple of questions that Zeljko and Ben posed below, offer a few resources on how to engage with the repo, and give an update on the UI MVP userflow. If you have any questions, please let me know.
Responses to Zeljko and Ben's Questions
1 .We
could make inside the WIKI page some Collaboration, or maybe would be
great if we could rent some JIRA Spaces for developing the project
further. =>
Agreed, a board would be convenient to organize ourselves and help
prioritize what is a P0 feature versus nice to haves. @all, do we
already have a board tool available? I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help 2. We could use Mocha and Cucumber for testing the model before deploying =>
I've never used Cucumber but if we have time to write some proper unit
tests before the deadline then yes, we should. I'll try to include some
proper user stories we can turn into tests sometime next week. My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-). 3.
We should check the Child-Parent Relationships (Asset-Owner and
changing of the owner in the Supply Chain) I would recommend here the
analogue to the Reversible Relationships =>
I'm using a tree based structure where every change of state
(split/pooling) triggers the creation of a new asset ID. This isn't
quite the same as RR (you can revert back into the original asset ID)
but with every node being linked to both parent and child this allows
for complete traceability. No comment
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions. Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to have. => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute. Yay, documentation!
@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.
Recommended approach for working with the Donor Milk code repository
I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?
Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.
Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!): - The link to the github docs that outlines and explains
how to create a pull request to add files from a fork
- Making your first pull request in Hyperledger: https://www.youtube.com/watch?v=f5XZe7dv0_U
- Here are a couple of more resources that may help:
- Tracy uses this workflow to sync her local fork - https://help.github.com/articles/syncing-a-fork/. There should probably be a step #6 which is a `git push` command to push the merged changes back to the local fork
Update on MPV UI Workflow
Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?
Best, M
Hi Zeljko,
Thanks for checking and sorry for the delay in answering. To your points:
1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further. => Agreed, a board would be convenient to organize ourselves and helo prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available? 2. We could use Mocha and Cucumber for testing the model before deploying => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week. 3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability. 4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions. 5. Some Documentation and Model Planning would be great to have. => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.
Thanks,
Ben. Hi,
I have seen the .CTO File from Ben.
@Benjamin - nice work with the assets and the Model.
I have maybe some suggestions.
1 .We could make inside the WIKI page some Collaboration , or maybe would be great if we could rent some JIRA Spaces for developing the project further. 2. We could use Mocha and Cucumber for testing the model before deploying 3. We should check the Child-Parrent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships 4. Maybe we could discusss topics in JIRA about the Owner Status of the milkAsset Asset 5. Some Documentation and Model Planing would be great to have.
I can offer my Jira skills and also Project Management skills within the Scope of this Project.
Kind Regards.
Zeljko Milinovic, MSc Certified Blockchain Architect Austria, Graz
Good Morning Ry,
Understood. True that ACL management is not particularly mature in Github. And as you point out, the implications can be sweeping.
It's too bad that we can't silo spinout projects of HL such as this to prevent this workflow limitation.
Appreciate the explanation... I suspected it was policy-related :/.
Thanks
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
On Tue, Sep 25, 2018 at 10:15 PM Ry Jones < rjones@...> wrote: It boils down to the GitHub default workflow. You don’t need anyone’s say-so to fork a public (or private) repo - you might need someone’s say-so to create a branch in a repo you don’t own.
There are further difficulties around this. GitHub’s ACL management leaves a lot to be desired - permissions I wish I could delegate are part of the Owner or Admin role; giving someone these roles grants very broad permissions, up to and including deleting the entire org.
The Linux Foundation position, pre-Hyperledger, was everyone needs to use Gerrit. In fact, some projects in Hyperledger are using Gerrit right now. Gerrit is not all sunshine and rainbows, though.
I personally find Gerrit more amenable, but GitHub has won the field. Ry
Good Afternoon,
Out of curiosity (perhaps this is HL policy), why generate so many forks instead of just creating separate branches? I'd think that, unless the forks lead to substantially different endpoints, it'd likely be easier to manage the branches (branching and merging is key when you have many devs working collaboratively). Again, not criticizing... just curious (and a learning opportunity for me).
--
Ry Jones Community Architect, Hyperledger
--
Benjamin Djidi
Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club
+33 762 001 145
|
|

Rich Bloch
Good Afternoon All,
This issue came up in our Hyperledger Seattle Meetup discussion on Slack recently.
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
toggle quoted messageShow quoted text
Hi to all,
I just came upon an article:
It seems so that IBM folks will no longer invest so much in Composer.
My question to all of you and especially to Ben, what are our alternatives?
Could we still use Javascript or we have to remodel and reprogram everything in Go language?
Kind Regards.
Zeljko Milinovic
Hi Marissa, Thanks for the great Email. I added my suggestions in bolded text. ____________________
Responses to Zeljko and Ben's Questions
1 .We could make inside the WIKI page some Collaboration, or
maybe would be great if we could rent some JIRA Spaces for developing the
project further.
=> Agreed, a board
would be convenient to organize ourselves and help prioritize what is a P0
feature versus nice to haves. @all, do we already have a board tool available?
I have made a request with Hyperledger Help Desk to get us a
JIRA workspace where we can organize ourselves. We confirmed that logging into
this tool will be via Linux Foundation ID, so it will ensure equal access to
everyone on the projects. TBD on when we get this, but I will keep everyone
posted. Friday we had discussed using the donor milk wiki as a placeholder for
requirements and stories (see Section 2). @Mikhail Elias you had mentioned wanting to use this as a
test case for some wiki work, so let me know how I can help
Thanks Marissa. I
think to make further great progress with the PoC the JIRA workspace is of a
great esence to the project, as I mentioned already. Team cannot continue to be
agile without this tool. Wiki is ok and we can collaborate here, but the
project needs more for the troubleshootings and builds.
2. We could use Mocha and Cucumber for testing the model
before deploying
=> I've never used
Cucumber but if we have time to write some proper unit tests before the
deadline then yes, we should. I'll try to include some proper user stories we
can turn into tests sometime next week.
Ben has built a great
.CTO model that I have reviewed and commented. I have learned a lot from his
model, great work Ben. As fort he Mocha and Cucumber, we can use these tools to
test the model before we get into further application development. Those are
great frameworks for testing the model assuming that we will have a lot of data
on the chain and to simulate those situations.
My knowledge is very limited here, but I'm assuming we're
talking about setting up a test network? In speaking with Tracy, she reminded
me that all Fabric nodes do not have to be in the same cloud server, so I have
reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's
offer is generous to stand up a VPS for the group, it is not ideal. If this is
not what you're referring to here, my comments are still relevant, just not for
this topic :-).
As fort he VPS instance,
maybe we could get on from the Linux Foundation. I offered help here and also
talked to Ben about this. This is also very important, because when we start to
build the WEB and MOBILE APPs , we would need a living REST Server and also to
achieve UNIT Testing without a living VPS instance will not be possible.
3. We should check the Child-Parent Relationships
(Asset-Owner and changing of the owner in the Supply Chain) I would recommend
here the analogue to the Reversible Relationships
=> I'm using a
tree based structure where every change of state (split/pooling) triggers the
creation of a new asset ID. This isn't quite the same as RR (you can revert
back into the original asset ID) but with every node being linked to both
parent and child this allows for complete traceability.
No comment
As for the
relationships, tree based what Ben did is great, but I think when we test this
model with simulating a lot of data with Mocha or Cucumber, we could come up on
performance issues with the Mobile app, becuase every change of state creates a
new Asset ID, an I was thinking with RR we have a unique ID for one asset from
the beginning of the life cycle. But this is something to be tested in the
future with Ben. May be that I am also wrong here, cannot really tell before I
test the Model on a live network VPS.
4. Maybe we could discuss topics in JIRA about the Owner
Status of the milkAsset Asset
=> This ties back
to 1. I've also made a pull request to the original repo so we'll be able to
create tickets for these discussions.
Yes, if people want to start logging issues in GitHub now
(as we wait for JIRA), please feel free to do so in the Issues Tab of the repo.
I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to
have.
=> Absolutely, the
reason why I forked in the first place was to experiment but with the pull I'll
be documenting (see 2) so that anyone can contribute.
Yay, documentation!
@Benjamin Djidi - are we still looking for someone to engage
on the access permissions work? Markus CC'd here had mentioned he had some
resources to lend, so we can pursue that if needed. Also, would it be helpful
to speak to the Identity Working Group on this? They have offered to come and
talk to the HCWG, so was wondering if this would be along the same vein or not.
As for the
relationships, this should not be a great issue. It needs to be defined (from
the Use Case and the processess that are now in use) which participants need to
access what and it can be coded pretty fast.
Recommended approach for working with the Donor Milk code
repository
I'd love for someone to write up a quick best practices for
engaging with the milk-donor repo code. I'm not the best person to do it.
Anyone interested?
Below are all of the resources we have so far. In addition
to the below we have confirmed that only members of the milk-donor-committers
team can actually merge a pull request: currently this is Angela, Ben, and
Zeljko. Let me know if others want to be included in this group.
Here are the resources that Angela, Ry and Tracy have sent
out (Many Thanks!):
The link to the github docs that outlines and explains how
to create a pull request to add files from a fork
https://help.github.com/articles/creating-a-pull-request-from-a-fork/
Making your first pull request in Hyperledger:
https://www.youtube.com/watch?v=f5XZe7dv0_U
Here are a couple of more resources that may help:
Gist on Contributing - Tracy made this for the Training and
Education WG, but if you change out https://github.com/hyperledger/education
and references to local education repository, the general ideas should apply to
the Milk Donor lab.
git Workflow Presentation - a presentation that is basically
identical to the above Gist.
Tracy uses this workflow to sync her local fork -
https://help.github.com/articles/syncing-a-fork/. There should probably be a
step #6 which is a `git push` command to push the merged changes back to the
local fork
Update on MPV UI Workflow
I know this is far from what the person creating the UI will
need, but I tried to breakdown the high- level flow by actors and then whether
or not the system was engaged at each step. This can be found in Section 2 of
the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx
Several questions came up for me while working on this,
especially around when the donor milk application was going to be used on a
computer vs a handheld for scanning, and how scanning would actually work in
the laboratory setting. I'd like to get feedback and then take this to our SMEs
for input. Thoughts?
We could use the Bar
Code or QRCode NodeJS libraries for scanning the assets for the apps. Just a
thought.
Kind regards. Zeljko Milinovic, MSc http://itstuffallaround.blogspot.com/
Hello Everyone!
We had a great meeting on Friday, and thanks to Ben for showing us what has been built in the network so far. We will have full notes posted shortly, but I wanted to respond to a couple of questions that Zeljko and Ben posed below, offer a few resources on how to engage with the repo, and give an update on the UI MVP userflow. If you have any questions, please let me know.
Responses to Zeljko and Ben's Questions
1 .We
could make inside the WIKI page some Collaboration, or maybe would be
great if we could rent some JIRA Spaces for developing the project
further. =>
Agreed, a board would be convenient to organize ourselves and help
prioritize what is a P0 feature versus nice to haves. @all, do we
already have a board tool available? I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help 2. We could use Mocha and Cucumber for testing the model before deploying =>
I've never used Cucumber but if we have time to write some proper unit
tests before the deadline then yes, we should. I'll try to include some
proper user stories we can turn into tests sometime next week. My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-). 3.
We should check the Child-Parent Relationships (Asset-Owner and
changing of the owner in the Supply Chain) I would recommend here the
analogue to the Reversible Relationships =>
I'm using a tree based structure where every change of state
(split/pooling) triggers the creation of a new asset ID. This isn't
quite the same as RR (you can revert back into the original asset ID)
but with every node being linked to both parent and child this allows
for complete traceability. No comment
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions. Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to have. => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute. Yay, documentation!
@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.
Recommended approach for working with the Donor Milk code repository
I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?
Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.
Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!): - The link to the github docs that outlines and explains
how to create a pull request to add files from a fork
- Making your first pull request in Hyperledger: https://www.youtube.com/watch?v=f5XZe7dv0_U
- Here are a couple of more resources that may help:
- Tracy uses this workflow to sync her local fork - https://help.github.com/articles/syncing-a-fork/. There should probably be a step #6 which is a `git push` command to push the merged changes back to the local fork
Update on MPV UI Workflow
Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?
Best, M
Hi Zeljko,
Thanks for checking and sorry for the delay in answering. To your points:
1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further. => Agreed, a board would be convenient to organize ourselves and helo prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available? 2. We could use Mocha and Cucumber for testing the model before deploying => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week. 3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability. 4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions. 5. Some Documentation and Model Planning would be great to have. => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.
Thanks,
Ben. Hi,
I have seen the .CTO File from Ben.
@Benjamin - nice work with the assets and the Model.
I have maybe some suggestions.
1 .We could make inside the WIKI page some Collaboration , or maybe would be great if we could rent some JIRA Spaces for developing the project further. 2. We could use Mocha and Cucumber for testing the model before deploying 3. We should check the Child-Parrent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships 4. Maybe we could discusss topics in JIRA about the Owner Status of the milkAsset Asset 5. Some Documentation and Model Planing would be great to have.
I can offer my Jira skills and also Project Management skills within the Scope of this Project.
Kind Regards.
Zeljko Milinovic, MSc Certified Blockchain Architect Austria, Graz
Good Morning Ry,
Understood. True that ACL management is not particularly mature in Github. And as you point out, the implications can be sweeping.
It's too bad that we can't silo spinout projects of HL such as this to prevent this workflow limitation.
Appreciate the explanation... I suspected it was policy-related :/.
Thanks
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
On Tue, Sep 25, 2018 at 10:15 PM Ry Jones < rjones@...> wrote: It boils down to the GitHub default workflow. You don’t need anyone’s say-so to fork a public (or private) repo - you might need someone’s say-so to create a branch in a repo you don’t own.
There are further difficulties around this. GitHub’s ACL management leaves a lot to be desired - permissions I wish I could delegate are part of the Owner or Admin role; giving someone these roles grants very broad permissions, up to and including deleting the entire org.
The Linux Foundation position, pre-Hyperledger, was everyone needs to use Gerrit. In fact, some projects in Hyperledger are using Gerrit right now. Gerrit is not all sunshine and rainbows, though.
I personally find Gerrit more amenable, but GitHub has won the field. Ry
Good Afternoon,
Out of curiosity (perhaps this is HL policy), why generate so many forks instead of just creating separate branches? I'd think that, unless the forks lead to substantially different endpoints, it'd likely be easier to manage the branches (branching and merging is key when you have many devs working collaboratively). Again, not criticizing... just curious (and a learning opportunity for me).
--
Ry Jones Community Architect, Hyperledger
--
Benjamin Djidi
Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club
+33 762 001 145
|
|
Zeljko Milinovic <zeljko.milgrz@...>
Hi,
Yes I have seen the Convector. But the question is, is it under Hyperledger Umbrella. Will it be supported native in the future. Is it better to use an Nodejs shim alternative?
Kr
Zeljko Milinovic
toggle quoted messageShow quoted text
Good Afternoon All,
This issue came up in our Hyperledger Seattle Meetup discussion on Slack recently.
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
Hi to all,
I just came upon an article:
It seems so that IBM folks will no longer invest so much in Composer.
My question to all of you and especially to Ben, what are our alternatives?
Could we still use Javascript or we have to remodel and reprogram everything in Go language?
Kind Regards.
Zeljko Milinovic
Hi Marissa, Thanks for the great Email. I added my suggestions in bolded text. ____________________
Responses to Zeljko and Ben's Questions
1 .We could make inside the WIKI page some Collaboration, or
maybe would be great if we could rent some JIRA Spaces for developing the
project further.
=> Agreed, a board
would be convenient to organize ourselves and help prioritize what is a P0
feature versus nice to haves. @all, do we already have a board tool available?
I have made a request with Hyperledger Help Desk to get us a
JIRA workspace where we can organize ourselves. We confirmed that logging into
this tool will be via Linux Foundation ID, so it will ensure equal access to
everyone on the projects. TBD on when we get this, but I will keep everyone
posted. Friday we had discussed using the donor milk wiki as a placeholder for
requirements and stories (see Section 2). @Mikhail Elias you had mentioned wanting to use this as a
test case for some wiki work, so let me know how I can help
Thanks Marissa. I
think to make further great progress with the PoC the JIRA workspace is of a
great esence to the project, as I mentioned already. Team cannot continue to be
agile without this tool. Wiki is ok and we can collaborate here, but the
project needs more for the troubleshootings and builds.
2. We could use Mocha and Cucumber for testing the model
before deploying
=> I've never used
Cucumber but if we have time to write some proper unit tests before the
deadline then yes, we should. I'll try to include some proper user stories we
can turn into tests sometime next week.
Ben has built a great
.CTO model that I have reviewed and commented. I have learned a lot from his
model, great work Ben. As fort he Mocha and Cucumber, we can use these tools to
test the model before we get into further application development. Those are
great frameworks for testing the model assuming that we will have a lot of data
on the chain and to simulate those situations.
My knowledge is very limited here, but I'm assuming we're
talking about setting up a test network? In speaking with Tracy, she reminded
me that all Fabric nodes do not have to be in the same cloud server, so I have
reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's
offer is generous to stand up a VPS for the group, it is not ideal. If this is
not what you're referring to here, my comments are still relevant, just not for
this topic :-).
As fort he VPS instance,
maybe we could get on from the Linux Foundation. I offered help here and also
talked to Ben about this. This is also very important, because when we start to
build the WEB and MOBILE APPs , we would need a living REST Server and also to
achieve UNIT Testing without a living VPS instance will not be possible.
3. We should check the Child-Parent Relationships
(Asset-Owner and changing of the owner in the Supply Chain) I would recommend
here the analogue to the Reversible Relationships
=> I'm using a
tree based structure where every change of state (split/pooling) triggers the
creation of a new asset ID. This isn't quite the same as RR (you can revert
back into the original asset ID) but with every node being linked to both
parent and child this allows for complete traceability.
No comment
As for the
relationships, tree based what Ben did is great, but I think when we test this
model with simulating a lot of data with Mocha or Cucumber, we could come up on
performance issues with the Mobile app, becuase every change of state creates a
new Asset ID, an I was thinking with RR we have a unique ID for one asset from
the beginning of the life cycle. But this is something to be tested in the
future with Ben. May be that I am also wrong here, cannot really tell before I
test the Model on a live network VPS.
4. Maybe we could discuss topics in JIRA about the Owner
Status of the milkAsset Asset
=> This ties back
to 1. I've also made a pull request to the original repo so we'll be able to
create tickets for these discussions.
Yes, if people want to start logging issues in GitHub now
(as we wait for JIRA), please feel free to do so in the Issues Tab of the repo.
I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to
have.
=> Absolutely, the
reason why I forked in the first place was to experiment but with the pull I'll
be documenting (see 2) so that anyone can contribute.
Yay, documentation!
@Benjamin Djidi - are we still looking for someone to engage
on the access permissions work? Markus CC'd here had mentioned he had some
resources to lend, so we can pursue that if needed. Also, would it be helpful
to speak to the Identity Working Group on this? They have offered to come and
talk to the HCWG, so was wondering if this would be along the same vein or not.
As for the
relationships, this should not be a great issue. It needs to be defined (from
the Use Case and the processess that are now in use) which participants need to
access what and it can be coded pretty fast.
Recommended approach for working with the Donor Milk code
repository
I'd love for someone to write up a quick best practices for
engaging with the milk-donor repo code. I'm not the best person to do it.
Anyone interested?
Below are all of the resources we have so far. In addition
to the below we have confirmed that only members of the milk-donor-committers
team can actually merge a pull request: currently this is Angela, Ben, and
Zeljko. Let me know if others want to be included in this group.
Here are the resources that Angela, Ry and Tracy have sent
out (Many Thanks!):
The link to the github docs that outlines and explains how
to create a pull request to add files from a fork
https://help.github.com/articles/creating-a-pull-request-from-a-fork/
Making your first pull request in Hyperledger:
https://www.youtube.com/watch?v=f5XZe7dv0_U
Here are a couple of more resources that may help:
Gist on Contributing - Tracy made this for the Training and
Education WG, but if you change out https://github.com/hyperledger/education
and references to local education repository, the general ideas should apply to
the Milk Donor lab.
git Workflow Presentation - a presentation that is basically
identical to the above Gist.
Tracy uses this workflow to sync her local fork -
https://help.github.com/articles/syncing-a-fork/. There should probably be a
step #6 which is a `git push` command to push the merged changes back to the
local fork
Update on MPV UI Workflow
I know this is far from what the person creating the UI will
need, but I tried to breakdown the high- level flow by actors and then whether
or not the system was engaged at each step. This can be found in Section 2 of
the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx
Several questions came up for me while working on this,
especially around when the donor milk application was going to be used on a
computer vs a handheld for scanning, and how scanning would actually work in
the laboratory setting. I'd like to get feedback and then take this to our SMEs
for input. Thoughts?
We could use the Bar
Code or QRCode NodeJS libraries for scanning the assets for the apps. Just a
thought.
Kind regards. Zeljko Milinovic, MSc http://itstuffallaround.blogspot.com/
Hello Everyone!
We had a great meeting on Friday, and thanks to Ben for showing us what has been built in the network so far. We will have full notes posted shortly, but I wanted to respond to a couple of questions that Zeljko and Ben posed below, offer a few resources on how to engage with the repo, and give an update on the UI MVP userflow. If you have any questions, please let me know.
Responses to Zeljko and Ben's Questions
1 .We
could make inside the WIKI page some Collaboration, or maybe would be
great if we could rent some JIRA Spaces for developing the project
further. =>
Agreed, a board would be convenient to organize ourselves and help
prioritize what is a P0 feature versus nice to haves. @all, do we
already have a board tool available? I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help 2. We could use Mocha and Cucumber for testing the model before deploying =>
I've never used Cucumber but if we have time to write some proper unit
tests before the deadline then yes, we should. I'll try to include some
proper user stories we can turn into tests sometime next week. My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-). 3.
We should check the Child-Parent Relationships (Asset-Owner and
changing of the owner in the Supply Chain) I would recommend here the
analogue to the Reversible Relationships =>
I'm using a tree based structure where every change of state
(split/pooling) triggers the creation of a new asset ID. This isn't
quite the same as RR (you can revert back into the original asset ID)
but with every node being linked to both parent and child this allows
for complete traceability. No comment
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions. Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to have. => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute. Yay, documentation!
@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.
Recommended approach for working with the Donor Milk code repository
I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?
Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.
Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!): - The link to the github docs that outlines and explains
how to create a pull request to add files from a fork
- Making your first pull request in Hyperledger: https://www.youtube.com/watch?v=f5XZe7dv0_U
- Here are a couple of more resources that may help:
- Tracy uses this workflow to sync her local fork - https://help.github.com/articles/syncing-a-fork/. There should probably be a step #6 which is a `git push` command to push the merged changes back to the local fork
Update on MPV UI Workflow
Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?
Best, M
Hi Zeljko,
Thanks for checking and sorry for the delay in answering. To your points:
1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further. => Agreed, a board would be convenient to organize ourselves and helo prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available? 2. We could use Mocha and Cucumber for testing the model before deploying => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week. 3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability. 4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions. 5. Some Documentation and Model Planning would be great to have. => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.
Thanks,
Ben. Hi,
I have seen the .CTO File from Ben.
@Benjamin - nice work with the assets and the Model.
I have maybe some suggestions.
1 .We could make inside the WIKI page some Collaboration , or maybe would be great if we could rent some JIRA Spaces for developing the project further. 2. We could use Mocha and Cucumber for testing the model before deploying 3. We should check the Child-Parrent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships 4. Maybe we could discusss topics in JIRA about the Owner Status of the milkAsset Asset 5. Some Documentation and Model Planing would be great to have.
I can offer my Jira skills and also Project Management skills within the Scope of this Project.
Kind Regards.
Zeljko Milinovic, MSc Certified Blockchain Architect Austria, Graz
Good Morning Ry,
Understood. True that ACL management is not particularly mature in Github. And as you point out, the implications can be sweeping.
It's too bad that we can't silo spinout projects of HL such as this to prevent this workflow limitation.
Appreciate the explanation... I suspected it was policy-related :/.
Thanks
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
On Tue, Sep 25, 2018 at 10:15 PM Ry Jones < rjones@...> wrote: It boils down to the GitHub default workflow. You don’t need anyone’s say-so to fork a public (or private) repo - you might need someone’s say-so to create a branch in a repo you don’t own.
There are further difficulties around this. GitHub’s ACL management leaves a lot to be desired - permissions I wish I could delegate are part of the Owner or Admin role; giving someone these roles grants very broad permissions, up to and including deleting the entire org.
The Linux Foundation position, pre-Hyperledger, was everyone needs to use Gerrit. In fact, some projects in Hyperledger are using Gerrit right now. Gerrit is not all sunshine and rainbows, though.
I personally find Gerrit more amenable, but GitHub has won the field. Ry
Good Afternoon,
Out of curiosity (perhaps this is HL policy), why generate so many forks instead of just creating separate branches? I'd think that, unless the forks lead to substantially different endpoints, it'd likely be easier to manage the branches (branching and merging is key when you have many devs working collaboratively). Again, not criticizing... just curious (and a learning opportunity for me).
--
Ry Jones Community Architect, Hyperledger
--
Benjamin Djidi
Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club
+33 762 001 145
|
|

Rich Bloch
Good Afternoon Zeljko,
I see that you're bringing this issue up on both the #Fabric and #Composer channels, which is the right thing to do.
On those channels, it seems that there's really no coherent "go forward" strategy in place... yet.
For me, it'd depend more on the shorter term, and where the team devs' interests lay. As an example, I'm not a particular fan of JS/ECMAScript, but would prefer TypeScript over both. That said, I'd opt for GoLang over TS. Again, this is really a personal thing.
I'd be interested to get some insight from Ry and others on this listserv who may have an ear to the ground on this topic ;).
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
toggle quoted messageShow quoted text
Hi,
Yes I have seen the Convector. But the question is, is it under Hyperledger Umbrella. Will it be supported native in the future. Is it better to use an Nodejs shim alternative?
Kr
Zeljko Milinovic Good Afternoon All,
This issue came up in our Hyperledger Seattle Meetup discussion on Slack recently.
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
Hi to all,
I just came upon an article:
It seems so that IBM folks will no longer invest so much in Composer.
My question to all of you and especially to Ben, what are our alternatives?
Could we still use Javascript or we have to remodel and reprogram everything in Go language?
Kind Regards.
Zeljko Milinovic
Hi Marissa, Thanks for the great Email. I added my suggestions in bolded text. ____________________
Responses to Zeljko and Ben's Questions
1 .We could make inside the WIKI page some Collaboration, or
maybe would be great if we could rent some JIRA Spaces for developing the
project further.
=> Agreed, a board
would be convenient to organize ourselves and help prioritize what is a P0
feature versus nice to haves. @all, do we already have a board tool available?
I have made a request with Hyperledger Help Desk to get us a
JIRA workspace where we can organize ourselves. We confirmed that logging into
this tool will be via Linux Foundation ID, so it will ensure equal access to
everyone on the projects. TBD on when we get this, but I will keep everyone
posted. Friday we had discussed using the donor milk wiki as a placeholder for
requirements and stories (see Section 2). @Mikhail Elias you had mentioned wanting to use this as a
test case for some wiki work, so let me know how I can help
Thanks Marissa. I
think to make further great progress with the PoC the JIRA workspace is of a
great esence to the project, as I mentioned already. Team cannot continue to be
agile without this tool. Wiki is ok and we can collaborate here, but the
project needs more for the troubleshootings and builds.
2. We could use Mocha and Cucumber for testing the model
before deploying
=> I've never used
Cucumber but if we have time to write some proper unit tests before the
deadline then yes, we should. I'll try to include some proper user stories we
can turn into tests sometime next week.
Ben has built a great
.CTO model that I have reviewed and commented. I have learned a lot from his
model, great work Ben. As fort he Mocha and Cucumber, we can use these tools to
test the model before we get into further application development. Those are
great frameworks for testing the model assuming that we will have a lot of data
on the chain and to simulate those situations.
My knowledge is very limited here, but I'm assuming we're
talking about setting up a test network? In speaking with Tracy, she reminded
me that all Fabric nodes do not have to be in the same cloud server, so I have
reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's
offer is generous to stand up a VPS for the group, it is not ideal. If this is
not what you're referring to here, my comments are still relevant, just not for
this topic :-).
As fort he VPS instance,
maybe we could get on from the Linux Foundation. I offered help here and also
talked to Ben about this. This is also very important, because when we start to
build the WEB and MOBILE APPs , we would need a living REST Server and also to
achieve UNIT Testing without a living VPS instance will not be possible.
3. We should check the Child-Parent Relationships
(Asset-Owner and changing of the owner in the Supply Chain) I would recommend
here the analogue to the Reversible Relationships
=> I'm using a
tree based structure where every change of state (split/pooling) triggers the
creation of a new asset ID. This isn't quite the same as RR (you can revert
back into the original asset ID) but with every node being linked to both
parent and child this allows for complete traceability.
No comment
As for the
relationships, tree based what Ben did is great, but I think when we test this
model with simulating a lot of data with Mocha or Cucumber, we could come up on
performance issues with the Mobile app, becuase every change of state creates a
new Asset ID, an I was thinking with RR we have a unique ID for one asset from
the beginning of the life cycle. But this is something to be tested in the
future with Ben. May be that I am also wrong here, cannot really tell before I
test the Model on a live network VPS.
4. Maybe we could discuss topics in JIRA about the Owner
Status of the milkAsset Asset
=> This ties back
to 1. I've also made a pull request to the original repo so we'll be able to
create tickets for these discussions.
Yes, if people want to start logging issues in GitHub now
(as we wait for JIRA), please feel free to do so in the Issues Tab of the repo.
I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to
have.
=> Absolutely, the
reason why I forked in the first place was to experiment but with the pull I'll
be documenting (see 2) so that anyone can contribute.
Yay, documentation!
@Benjamin Djidi - are we still looking for someone to engage
on the access permissions work? Markus CC'd here had mentioned he had some
resources to lend, so we can pursue that if needed. Also, would it be helpful
to speak to the Identity Working Group on this? They have offered to come and
talk to the HCWG, so was wondering if this would be along the same vein or not.
As for the
relationships, this should not be a great issue. It needs to be defined (from
the Use Case and the processess that are now in use) which participants need to
access what and it can be coded pretty fast.
Recommended approach for working with the Donor Milk code
repository
I'd love for someone to write up a quick best practices for
engaging with the milk-donor repo code. I'm not the best person to do it.
Anyone interested?
Below are all of the resources we have so far. In addition
to the below we have confirmed that only members of the milk-donor-committers
team can actually merge a pull request: currently this is Angela, Ben, and
Zeljko. Let me know if others want to be included in this group.
Here are the resources that Angela, Ry and Tracy have sent
out (Many Thanks!):
The link to the github docs that outlines and explains how
to create a pull request to add files from a fork
https://help.github.com/articles/creating-a-pull-request-from-a-fork/
Making your first pull request in Hyperledger:
https://www.youtube.com/watch?v=f5XZe7dv0_U
Here are a couple of more resources that may help:
Gist on Contributing - Tracy made this for the Training and
Education WG, but if you change out https://github.com/hyperledger/education
and references to local education repository, the general ideas should apply to
the Milk Donor lab.
git Workflow Presentation - a presentation that is basically
identical to the above Gist.
Tracy uses this workflow to sync her local fork -
https://help.github.com/articles/syncing-a-fork/. There should probably be a
step #6 which is a `git push` command to push the merged changes back to the
local fork
Update on MPV UI Workflow
I know this is far from what the person creating the UI will
need, but I tried to breakdown the high- level flow by actors and then whether
or not the system was engaged at each step. This can be found in Section 2 of
the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx
Several questions came up for me while working on this,
especially around when the donor milk application was going to be used on a
computer vs a handheld for scanning, and how scanning would actually work in
the laboratory setting. I'd like to get feedback and then take this to our SMEs
for input. Thoughts?
We could use the Bar
Code or QRCode NodeJS libraries for scanning the assets for the apps. Just a
thought.
Kind regards. Zeljko Milinovic, MSc http://itstuffallaround.blogspot.com/
Hello Everyone!
We had a great meeting on Friday, and thanks to Ben for showing us what has been built in the network so far. We will have full notes posted shortly, but I wanted to respond to a couple of questions that Zeljko and Ben posed below, offer a few resources on how to engage with the repo, and give an update on the UI MVP userflow. If you have any questions, please let me know.
Responses to Zeljko and Ben's Questions
1 .We
could make inside the WIKI page some Collaboration, or maybe would be
great if we could rent some JIRA Spaces for developing the project
further. =>
Agreed, a board would be convenient to organize ourselves and help
prioritize what is a P0 feature versus nice to haves. @all, do we
already have a board tool available? I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help 2. We could use Mocha and Cucumber for testing the model before deploying =>
I've never used Cucumber but if we have time to write some proper unit
tests before the deadline then yes, we should. I'll try to include some
proper user stories we can turn into tests sometime next week. My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-). 3.
We should check the Child-Parent Relationships (Asset-Owner and
changing of the owner in the Supply Chain) I would recommend here the
analogue to the Reversible Relationships =>
I'm using a tree based structure where every change of state
(split/pooling) triggers the creation of a new asset ID. This isn't
quite the same as RR (you can revert back into the original asset ID)
but with every node being linked to both parent and child this allows
for complete traceability. No comment
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions. Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to have. => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute. Yay, documentation!
@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.
Recommended approach for working with the Donor Milk code repository
I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?
Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.
Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!): - The link to the github docs that outlines and explains
how to create a pull request to add files from a fork
- Making your first pull request in Hyperledger: https://www.youtube.com/watch?v=f5XZe7dv0_U
- Here are a couple of more resources that may help:
- Tracy uses this workflow to sync her local fork - https://help.github.com/articles/syncing-a-fork/. There should probably be a step #6 which is a `git push` command to push the merged changes back to the local fork
Update on MPV UI Workflow
Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?
Best, M
Hi Zeljko,
Thanks for checking and sorry for the delay in answering. To your points:
1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further. => Agreed, a board would be convenient to organize ourselves and helo prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available? 2. We could use Mocha and Cucumber for testing the model before deploying => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week. 3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability. 4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions. 5. Some Documentation and Model Planning would be great to have. => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.
Thanks,
Ben. Hi,
I have seen the .CTO File from Ben.
@Benjamin - nice work with the assets and the Model.
I have maybe some suggestions.
1 .We could make inside the WIKI page some Collaboration , or maybe would be great if we could rent some JIRA Spaces for developing the project further. 2. We could use Mocha and Cucumber for testing the model before deploying 3. We should check the Child-Parrent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships 4. Maybe we could discusss topics in JIRA about the Owner Status of the milkAsset Asset 5. Some Documentation and Model Planing would be great to have.
I can offer my Jira skills and also Project Management skills within the Scope of this Project.
Kind Regards.
Zeljko Milinovic, MSc Certified Blockchain Architect Austria, Graz
Good Morning Ry,
Understood. True that ACL management is not particularly mature in Github. And as you point out, the implications can be sweeping.
It's too bad that we can't silo spinout projects of HL such as this to prevent this workflow limitation.
Appreciate the explanation... I suspected it was policy-related :/.
Thanks
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
On Tue, Sep 25, 2018 at 10:15 PM Ry Jones < rjones@...> wrote: It boils down to the GitHub default workflow. You don’t need anyone’s say-so to fork a public (or private) repo - you might need someone’s say-so to create a branch in a repo you don’t own.
There are further difficulties around this. GitHub’s ACL management leaves a lot to be desired - permissions I wish I could delegate are part of the Owner or Admin role; giving someone these roles grants very broad permissions, up to and including deleting the entire org.
The Linux Foundation position, pre-Hyperledger, was everyone needs to use Gerrit. In fact, some projects in Hyperledger are using Gerrit right now. Gerrit is not all sunshine and rainbows, though.
I personally find Gerrit more amenable, but GitHub has won the field. Ry
Good Afternoon,
Out of curiosity (perhaps this is HL policy), why generate so many forks instead of just creating separate branches? I'd think that, unless the forks lead to substantially different endpoints, it'd likely be easier to manage the branches (branching and merging is key when you have many devs working collaboratively). Again, not criticizing... just curious (and a learning opportunity for me).
--
Ry Jones Community Architect, Hyperledger
--
Benjamin Djidi
Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club
+33 762 001 145
|
|
Benjamin Djidi <benjamin.djidi@...>
Hi all,
Thanks for the article Rich. As it greatly underlines, you have two options: Go or Node. It seems that a lot of the examples are now being written in go (see the marble contracts) but Node is very popular and I imagine more helpers will start popping up (I'm yet to play with convector). That being said, both the chat and doc seem to go the Go way (pun intended). Would be great to have contributors weight in.
Cheers,
Ben.
toggle quoted messageShow quoted text
Good Afternoon Zeljko,
I see that you're bringing this issue up on both the #Fabric and #Composer channels, which is the right thing to do.
On those channels, it seems that there's really no coherent "go forward" strategy in place... yet.
For me, it'd depend more on the shorter term, and where the team devs' interests lay. As an example, I'm not a particular fan of JS/ECMAScript, but would prefer TypeScript over both. That said, I'd opt for GoLang over TS. Again, this is really a personal thing.
I'd be interested to get some insight from Ry and others on this listserv who may have an ear to the ground on this topic ;).
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
Hi,
Yes I have seen the Convector. But the question is, is it under Hyperledger Umbrella. Will it be supported native in the future. Is it better to use an Nodejs shim alternative?
Kr
Zeljko Milinovic Good Afternoon All,
This issue came up in our Hyperledger Seattle Meetup discussion on Slack recently.
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
Hi to all,
I just came upon an article:
It seems so that IBM folks will no longer invest so much in Composer.
My question to all of you and especially to Ben, what are our alternatives?
Could we still use Javascript or we have to remodel and reprogram everything in Go language?
Kind Regards.
Zeljko Milinovic
Hi Marissa, Thanks for the great Email. I added my suggestions in bolded text. ____________________
Responses to Zeljko and Ben's Questions
1 .We could make inside the WIKI page some Collaboration, or
maybe would be great if we could rent some JIRA Spaces for developing the
project further.
=> Agreed, a board
would be convenient to organize ourselves and help prioritize what is a P0
feature versus nice to haves. @all, do we already have a board tool available?
I have made a request with Hyperledger Help Desk to get us a
JIRA workspace where we can organize ourselves. We confirmed that logging into
this tool will be via Linux Foundation ID, so it will ensure equal access to
everyone on the projects. TBD on when we get this, but I will keep everyone
posted. Friday we had discussed using the donor milk wiki as a placeholder for
requirements and stories (see Section 2). @Mikhail Elias you had mentioned wanting to use this as a
test case for some wiki work, so let me know how I can help
Thanks Marissa. I
think to make further great progress with the PoC the JIRA workspace is of a
great esence to the project, as I mentioned already. Team cannot continue to be
agile without this tool. Wiki is ok and we can collaborate here, but the
project needs more for the troubleshootings and builds.
2. We could use Mocha and Cucumber for testing the model
before deploying
=> I've never used
Cucumber but if we have time to write some proper unit tests before the
deadline then yes, we should. I'll try to include some proper user stories we
can turn into tests sometime next week.
Ben has built a great
.CTO model that I have reviewed and commented. I have learned a lot from his
model, great work Ben. As fort he Mocha and Cucumber, we can use these tools to
test the model before we get into further application development. Those are
great frameworks for testing the model assuming that we will have a lot of data
on the chain and to simulate those situations.
My knowledge is very limited here, but I'm assuming we're
talking about setting up a test network? In speaking with Tracy, she reminded
me that all Fabric nodes do not have to be in the same cloud server, so I have
reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's
offer is generous to stand up a VPS for the group, it is not ideal. If this is
not what you're referring to here, my comments are still relevant, just not for
this topic :-).
As fort he VPS instance,
maybe we could get on from the Linux Foundation. I offered help here and also
talked to Ben about this. This is also very important, because when we start to
build the WEB and MOBILE APPs , we would need a living REST Server and also to
achieve UNIT Testing without a living VPS instance will not be possible.
3. We should check the Child-Parent Relationships
(Asset-Owner and changing of the owner in the Supply Chain) I would recommend
here the analogue to the Reversible Relationships
=> I'm using a
tree based structure where every change of state (split/pooling) triggers the
creation of a new asset ID. This isn't quite the same as RR (you can revert
back into the original asset ID) but with every node being linked to both
parent and child this allows for complete traceability.
No comment
As for the
relationships, tree based what Ben did is great, but I think when we test this
model with simulating a lot of data with Mocha or Cucumber, we could come up on
performance issues with the Mobile app, becuase every change of state creates a
new Asset ID, an I was thinking with RR we have a unique ID for one asset from
the beginning of the life cycle. But this is something to be tested in the
future with Ben. May be that I am also wrong here, cannot really tell before I
test the Model on a live network VPS.
4. Maybe we could discuss topics in JIRA about the Owner
Status of the milkAsset Asset
=> This ties back
to 1. I've also made a pull request to the original repo so we'll be able to
create tickets for these discussions.
Yes, if people want to start logging issues in GitHub now
(as we wait for JIRA), please feel free to do so in the Issues Tab of the repo.
I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to
have.
=> Absolutely, the
reason why I forked in the first place was to experiment but with the pull I'll
be documenting (see 2) so that anyone can contribute.
Yay, documentation!
@Benjamin Djidi - are we still looking for someone to engage
on the access permissions work? Markus CC'd here had mentioned he had some
resources to lend, so we can pursue that if needed. Also, would it be helpful
to speak to the Identity Working Group on this? They have offered to come and
talk to the HCWG, so was wondering if this would be along the same vein or not.
As for the
relationships, this should not be a great issue. It needs to be defined (from
the Use Case and the processess that are now in use) which participants need to
access what and it can be coded pretty fast.
Recommended approach for working with the Donor Milk code
repository
I'd love for someone to write up a quick best practices for
engaging with the milk-donor repo code. I'm not the best person to do it.
Anyone interested?
Below are all of the resources we have so far. In addition
to the below we have confirmed that only members of the milk-donor-committers
team can actually merge a pull request: currently this is Angela, Ben, and
Zeljko. Let me know if others want to be included in this group.
Here are the resources that Angela, Ry and Tracy have sent
out (Many Thanks!):
The link to the github docs that outlines and explains how
to create a pull request to add files from a fork
https://help.github.com/articles/creating-a-pull-request-from-a-fork/
Making your first pull request in Hyperledger:
https://www.youtube.com/watch?v=f5XZe7dv0_U
Here are a couple of more resources that may help:
Gist on Contributing - Tracy made this for the Training and
Education WG, but if you change out https://github.com/hyperledger/education
and references to local education repository, the general ideas should apply to
the Milk Donor lab.
git Workflow Presentation - a presentation that is basically
identical to the above Gist.
Tracy uses this workflow to sync her local fork -
https://help.github.com/articles/syncing-a-fork/. There should probably be a
step #6 which is a `git push` command to push the merged changes back to the
local fork
Update on MPV UI Workflow
I know this is far from what the person creating the UI will
need, but I tried to breakdown the high- level flow by actors and then whether
or not the system was engaged at each step. This can be found in Section 2 of
the Wiki in a PPT: happy_path_mpv_flow_for_donor_milk.pptx
Several questions came up for me while working on this,
especially around when the donor milk application was going to be used on a
computer vs a handheld for scanning, and how scanning would actually work in
the laboratory setting. I'd like to get feedback and then take this to our SMEs
for input. Thoughts?
We could use the Bar
Code or QRCode NodeJS libraries for scanning the assets for the apps. Just a
thought.
Kind regards. Zeljko Milinovic, MSc http://itstuffallaround.blogspot.com/
Hello Everyone!
We had a great meeting on Friday, and thanks to Ben for showing us what has been built in the network so far. We will have full notes posted shortly, but I wanted to respond to a couple of questions that Zeljko and Ben posed below, offer a few resources on how to engage with the repo, and give an update on the UI MVP userflow. If you have any questions, please let me know.
Responses to Zeljko and Ben's Questions
1 .We
could make inside the WIKI page some Collaboration, or maybe would be
great if we could rent some JIRA Spaces for developing the project
further. =>
Agreed, a board would be convenient to organize ourselves and help
prioritize what is a P0 feature versus nice to haves. @all, do we
already have a board tool available? I have made a request with Hyperledger Help Desk to get us a JIRA workspace where we can organize ourselves. We confirmed that logging into this tool will be via Linux Foundation ID, so it will ensure equal access to everyone on the projects. TBD on when we get this, but I will keep everyone posted. Friday we had discussed using the donor milk wiki as a placeholder for requirements and stories (see Section 2). @Mikhail Elias you had mentioned wanting to use this as a test case for some wiki work, so let me know how I can help 2. We could use Mocha and Cucumber for testing the model before deploying =>
I've never used Cucumber but if we have time to write some proper unit
tests before the deadline then yes, we should. I'll try to include some
proper user stories we can turn into tests sometime next week. My knowledge is very limited here, but I'm assuming we're talking about setting up a test network? In speaking with Tracy, she reminded me that all Fabric nodes do not have to be in the same cloud server, so I have reached out to the #fabric Rocket.Chat channel to seek advice here. While Zeljko's offer is generous to stand up a VPS for the group, it is not ideal. If this is not what you're referring to here, my comments are still relevant, just not for this topic :-). 3.
We should check the Child-Parent Relationships (Asset-Owner and
changing of the owner in the Supply Chain) I would recommend here the
analogue to the Reversible Relationships =>
I'm using a tree based structure where every change of state
(split/pooling) triggers the creation of a new asset ID. This isn't
quite the same as RR (you can revert back into the original asset ID)
but with every node being linked to both parent and child this allows
for complete traceability. No comment
4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions. Yes, if people want to start logging issues in GitHub now (as we wait for JIRA), please feel free to do so in the Issues Tab of the repo. I've created a "test issue" on this
5. Some Documentation and Model Planning would be great to have. => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute. Yay, documentation!
@Benjamin Djidi - are we still looking for someone to engage on the access permissions work? Markus CC'd here had mentioned he had some resources to lend, so we can pursue that if needed. Also, would it be helpful to speak to the Identity Working Group on this? They have offered to come and talk to the HCWG, so was wondering if this would be along the same vein or not.
Recommended approach for working with the Donor Milk code repository
I'd love for someone to write up a quick best practices for engaging with the milk-donor repo code. I'm not the best person to do it. Anyone interested?
Below are all of the resources we have so far. In addition to the below we have confirmed that only members of the milk-donor-committers team can actually merge a pull request: currently this is Angela, Ben, and Zeljko. Let me know if others want to be included in this group.
Here are the resources that Angela, Ry and Tracy have sent out (Many Thanks!): - The link to the github docs that outlines and explains
how to create a pull request to add files from a fork
- Making your first pull request in Hyperledger: https://www.youtube.com/watch?v=f5XZe7dv0_U
- Here are a couple of more resources that may help:
- Tracy uses this workflow to sync her local fork - https://help.github.com/articles/syncing-a-fork/. There should probably be a step #6 which is a `git push` command to push the merged changes back to the local fork
Update on MPV UI Workflow
Several questions came up for me while working on this, especially around when the donor milk application was going to be used on a computer vs a handheld for scanning, and how scanning would actually work in the laboratory setting. I'd like to get feedback and then take this to our SMEs for input. Thoughts?
Best, M
Hi Zeljko,
Thanks for checking and sorry for the delay in answering. To your points:
1 .We could make inside the WIKI page some Collaboration, or maybe would be great if we could rent some JIRA Spaces for developing the project further. => Agreed, a board would be convenient to organize ourselves and helo prioritize what is a P0 feature versus nice to haves. @all, do we already have a board tool available? 2. We could use Mocha and Cucumber for testing the model before deploying => I've never used Cucumber but if we have time to write some proper unit tests before the deadline then yes, we should. I'll try to include some proper user stories we can turn into tests sometime next week. 3. We should check the Child-Parent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships => I'm using a tree based structure where every change of state (split/pooling) triggers the creation of a new asset ID. This isn't quite the same as RR (you can revert back into the original asset ID) but with every node being linked to both parent and child this allows for complete traceability. 4. Maybe we could discuss topics in JIRA about the Owner Status of the milkAsset Asset => This ties back to 1. I've also made a pull request to the original repo so we'll be able to create tickets for these discussions. 5. Some Documentation and Model Planning would be great to have. => Absolutely, the reason why I forked in the first place was to experiment but with the pull I'll be documenting (see 2) so that anyone can contribute.
Thanks,
Ben. Hi,
I have seen the .CTO File from Ben.
@Benjamin - nice work with the assets and the Model.
I have maybe some suggestions.
1 .We could make inside the WIKI page some Collaboration , or maybe would be great if we could rent some JIRA Spaces for developing the project further. 2. We could use Mocha and Cucumber for testing the model before deploying 3. We should check the Child-Parrent Relationships (Asset-Owner and changing of the owner in the Supply Chain) I would recommend here the analogue to the Reversible Relationships 4. Maybe we could discusss topics in JIRA about the Owner Status of the milkAsset Asset 5. Some Documentation and Model Planing would be great to have.
I can offer my Jira skills and also Project Management skills within the Scope of this Project.
Kind Regards.
Zeljko Milinovic, MSc Certified Blockchain Architect Austria, Graz
Good Morning Ry,
Understood. True that ACL management is not particularly mature in Github. And as you point out, the implications can be sweeping.
It's too bad that we can't silo spinout projects of HL such as this to prevent this workflow limitation.
Appreciate the explanation... I suspected it was policy-related :/.
Thanks
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
On Tue, Sep 25, 2018 at 10:15 PM Ry Jones < rjones@...> wrote: It boils down to the GitHub default workflow. You don’t need anyone’s say-so to fork a public (or private) repo - you might need someone’s say-so to create a branch in a repo you don’t own.
There are further difficulties around this. GitHub’s ACL management leaves a lot to be desired - permissions I wish I could delegate are part of the Owner or Admin role; giving someone these roles grants very broad permissions, up to and including deleting the entire org.
The Linux Foundation position, pre-Hyperledger, was everyone needs to use Gerrit. In fact, some projects in Hyperledger are using Gerrit right now. Gerrit is not all sunshine and rainbows, though.
I personally find Gerrit more amenable, but GitHub has won the field. Ry
Good Afternoon,
Out of curiosity (perhaps this is HL policy), why generate so many forks instead of just creating separate branches? I'd think that, unless the forks lead to substantially different endpoints, it'd likely be easier to manage the branches (branching and merging is key when you have many devs working collaboratively). Again, not criticizing... just curious (and a learning opportunity for me).
--
Ry Jones Community Architect, Hyperledger
--
Benjamin Djidi
Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club
+33 762 001 145
-- Benjamin Djidi
Sr. BIE, Amazon International Expansion
Former Founding Partner, Revstr
President Emeritus, IESEG International Club
+33 762 001 145
|
|
ben.taylor@sophrosynecapital.com <ben.taylor@...>
Hi Ben, We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js
It’s a substantial investment but the client experience and server performance is truly enhanced.
Feel free to reach out if you have any questions,
toggle quoted messageShow quoted text
On Oct 1, 2018, at 8:49 PM, Benjamin Djidi < benjamin.djidi@...> wrote: Benjamin Djidi
Sr. BIE, Amazon International Expansion
|
|
Zeljko Milinovic <zeljko.milgrz@...>
Hi to both of the Bens :D
Thanks for the Input.
Here are my opinions and questions.
Convecta approach could go out of support like composer in one year. I think it is a no go soluion.
As Ben D. stated there are two options Go or Node.
Go lang is for sure faster because it is native. I see also that the link for the shim documentation on GItHub for NodeJS Core ChainCode SDK is not working. I hope that the contributors will work to put more weight into NodeJS.
As for Go. I had some questions for the Ben T. What are you using for modelling and defining the bussiness network (Assets, Pariticipants, Transactions), like we did in composer?
Any advice on how to approach the Architecture, Modelling and development Cycles would be really appreciated.
Kind regards.
Zeljko Am Di., 2. Okt. 2018 um 03:07 Uhr schrieb Ben Taylor < ben.taylor@...>:
toggle quoted messageShow quoted text
Hi Ben, We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js
It’s a substantial investment but the client experience and server performance is truly enhanced.
Feel free to reach out if you have any questions, Ben Benjamin Djidi
Sr. BIE, Amazon International Expansion
|
|
Mikhail Elias <hyperledger@...>
Another approach to consider would involve collaborating on modeling language development -- possibly within the context of the donor milk POC; this currently seems to be where the IBM UK team seems to be most interested in allocating resources.
This collaboration could serve to bridge between future work on tools to support 'front-end' SDLC activities - domain analysis and requirements development - and 'back-end' development, testing, etc.
We could plan our upcoming transition to Confluence to support rapid prototyping and feedback of some of these analysis and modeling tools.
|
|
ben.taylor@sophrosynecapital.com <ben.taylor@...>
Zeljko, We never used Composer at LedgerDomain so I’m not the best person to speak to that.
Happy to chat directly if you have any questions, just shoot me an email at
Ben
toggle quoted messageShow quoted text
On Oct 2, 2018, at 1:41 AM, Zeljko Milinovic < zeljko.milgrz@...> wrote: Hi to both of the Bens :D
Thanks for the Input.
Here are my opinions and questions.
Convecta approach could go out of support like composer in one year. I think it is a no go soluion.
As Ben D. stated there are two options Go or Node.
Go lang is for sure faster because it is native. I see also that the link for the shim documentation on GItHub for NodeJS Core ChainCode SDK is not working. I hope that the contributors will work to put more weight into NodeJS.
As for Go. I had some questions for the Ben T. What are you using for modelling and defining the bussiness network (Assets, Pariticipants, Transactions), like we did in composer?
Any advice on how to approach the Architecture, Modelling and development Cycles would be really appreciated.
Kind regards.
Zeljko Am Di., 2. Okt. 2018 um 03:07 Uhr schrieb Ben Taylor < ben.taylor@...>: Hi Ben, We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js
It’s a substantial investment but the client experience and server performance is truly enhanced.
Feel free to reach out if you have any questions, Ben Benjamin Djidi
Sr. BIE, Amazon International Expansion
|
|
I have worked with composer previously can I have a look at the bna file please? Please share me the link of repo.I will see what can be optimized. If someone has an EC2 instance to donate I can also make the bna live on restserver to store data on fabric network directly 😅 I hope that is useful for the community.
|
|
Mikhail Elias <hyperledger@...>
Please use the New Member Orientation wikipage to familiarize yourself with the project and to locate resources : https://wiki.hyperledger.org/groups/healthcare/orientation
Feel free to edit and update the page with any information currently missing.
|
|
Zeljko Milinovic <zeljko.milgrz@...>
Hi Ben T.,
Thanks for the input. Yes I understood that you never used Composer at LedgerDomain. This is also a great approach. I was thinking in the near future as soon as the PoC is over it will maybe need to go to production and this will not be possible with Composer. So I wanted to change the mindset and to switch also future PoC-es to Go Lang. That is why I wanted to ask for tips and insights on how to Model, Design a GoLang-Fabric PoC like we did with composer and .CTO Domain Language. And also how to test the models on the beginning and also how to define Assets/Participants/Transactions like we did in Hyperledger Composer.
Any links or tips would be very appreciated.
Thanks in advance.
Kind regards.
Zeljko Milinovic, MSc Am Di., 2. Okt. 2018 um 17:52 Uhr schrieb Ben Taylor < ben.taylor@...>:
toggle quoted messageShow quoted text
Zeljko, We never used Composer at LedgerDomain so I’m not the best person to speak to that.
Happy to chat directly if you have any questions, just shoot me an email at
Ben
Hi to both of the Bens :D
Thanks for the Input.
Here are my opinions and questions.
Convecta approach could go out of support like composer in one year. I think it is a no go soluion.
As Ben D. stated there are two options Go or Node.
Go lang is for sure faster because it is native. I see also that the link for the shim documentation on GItHub for NodeJS Core ChainCode SDK is not working. I hope that the contributors will work to put more weight into NodeJS.
As for Go. I had some questions for the Ben T. What are you using for modelling and defining the bussiness network (Assets, Pariticipants, Transactions), like we did in composer?
Any advice on how to approach the Architecture, Modelling and development Cycles would be really appreciated.
Kind regards.
Zeljko Am Di., 2. Okt. 2018 um 03:07 Uhr schrieb Ben Taylor < ben.taylor@...>: Hi Ben, We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js
It’s a substantial investment but the client experience and server performance is truly enhanced.
Feel free to reach out if you have any questions, Ben Benjamin Djidi
Sr. BIE, Amazon International Expansion
|
|

Rich Bloch
Good Afternoon All,
This is an excellent discussion with a lot of very good information that we can share with other subgroups (and even other WGs) going forward.
To keep member's inboxes reasonably clear, I'd recommend that longer threads get moved over to our Rocket.Chat channel, primarily because the chat channel will self-document discussions much easier for future reference.
Again, a great discussion!
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
toggle quoted messageShow quoted text
Hi Ben T.,
Thanks for the input. Yes I understood that you never used Composer at LedgerDomain. This is also a great approach. I was thinking in the near future as soon as the PoC is over it will maybe need to go to production and this will not be possible with Composer. So I wanted to change the mindset and to switch also future PoC-es to Go Lang. That is why I wanted to ask for tips and insights on how to Model, Design a GoLang-Fabric PoC like we did with composer and .CTO Domain Language. And also how to test the models on the beginning and also how to define Assets/Participants/Transactions like we did in Hyperledger Composer.
Any links or tips would be very appreciated.
Thanks in advance.
Kind regards.
Zeljko Milinovic, MSc
Am Di., 2. Okt. 2018 um 17:52 Uhr schrieb Ben Taylor < ben.taylor@...>: Zeljko, We never used Composer at LedgerDomain so I’m not the best person to speak to that.
Happy to chat directly if you have any questions, just shoot me an email at
Ben
Hi to both of the Bens :D
Thanks for the Input.
Here are my opinions and questions.
Convecta approach could go out of support like composer in one year. I think it is a no go soluion.
As Ben D. stated there are two options Go or Node.
Go lang is for sure faster because it is native. I see also that the link for the shim documentation on GItHub for NodeJS Core ChainCode SDK is not working. I hope that the contributors will work to put more weight into NodeJS.
As for Go. I had some questions for the Ben T. What are you using for modelling and defining the bussiness network (Assets, Pariticipants, Transactions), like we did in composer?
Any advice on how to approach the Architecture, Modelling and development Cycles would be really appreciated.
Kind regards.
Zeljko Am Di., 2. Okt. 2018 um 03:07 Uhr schrieb Ben Taylor < ben.taylor@...>: Hi Ben, We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js
It’s a substantial investment but the client experience and server performance is truly enhanced.
Feel free to reach out if you have any questions, Ben Benjamin Djidi
Sr. BIE, Amazon International Expansion
|
|
Hello all, Zeljko, I put up some links using GoLang inside the Rocket chat. Hopefully, they will be helpful to all who are interested as well. I also put up a link to obtain access to the IBM blockchain cloud which hosts the networks. You get 500 free credits to use to test the network using peers. Perhaps we as a project, should consider applying to obtain our IBM Network Enterprise license to host our network once it is production ready. Food for thought. Thanks! ( Zeljko, I can email you the links if you do not have access to the group's Rocket chat yet). Sincerely,
Founder Adrastia Biotech Corporation Dr. A. Courtney, CEO D.V.M., M.B.A., PhD Integrative Pathobiology U.C. Davis Alumna
toggle quoted messageShow quoted text
Good Afternoon All,
This is an excellent discussion with a lot of very good information that we can share with other subgroups (and even other WGs) going forward.
To keep member's inboxes reasonably clear, I'd recommend that longer threads get moved over to our Rocket.Chat channel, primarily because the chat channel will self-document discussions much easier for future reference.
Again, a great discussion!
Rich | Richard Bloch Principal, Business Learning Incorporated Systems & Software Engineering Seattle, Washington USA |
Hi Ben T.,
Thanks for the input. Yes I understood that you never used Composer at LedgerDomain. This is also a great approach. I was thinking in the near future as soon as the PoC is over it will maybe need to go to production and this will not be possible with Composer. So I wanted to change the mindset and to switch also future PoC-es to Go Lang. That is why I wanted to ask for tips and insights on how to Model, Design a GoLang-Fabric PoC like we did with composer and .CTO Domain Language. And also how to test the models on the beginning and also how to define Assets/Participants/Transactions like we did in Hyperledger Composer.
Any links or tips would be very appreciated.
Thanks in advance.
Kind regards.
Zeljko Milinovic, MSc
Am Di., 2. Okt. 2018 um 17:52 Uhr schrieb Ben Taylor < ben.taylor@...>: Zeljko, We never used Composer at LedgerDomain so I’m not the best person to speak to that.
Happy to chat directly if you have any questions, just shoot me an email at
Ben
Hi to both of the Bens :D
Thanks for the Input.
Here are my opinions and questions.
Convecta approach could go out of support like composer in one year. I think it is a no go soluion.
As Ben D. stated there are two options Go or Node.
Go lang is for sure faster because it is native. I see also that the link for the shim documentation on GItHub for NodeJS Core ChainCode SDK is not working. I hope that the contributors will work to put more weight into NodeJS.
As for Go. I had some questions for the Ben T. What are you using for modelling and defining the bussiness network (Assets, Pariticipants, Transactions), like we did in composer?
Any advice on how to approach the Architecture, Modelling and development Cycles would be really appreciated.
Kind regards.
Zeljko Am Di., 2. Okt. 2018 um 03:07 Uhr schrieb Ben Taylor < ben.taylor@...>: Hi Ben, We at LedgerDomain use Golang for everything including smart contracts and even wrote our own app server to replace and enhance node.js
It’s a substantial investment but the client experience and server performance is truly enhanced.
Feel free to reach out if you have any questions, Ben Benjamin Djidi
Sr. BIE, Amazon International Expansion
|
|