New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move us officially over to Next Generation #621

Open
yaronyg opened this Issue Mar 14, 2016 · 9 comments

Comments

Projects
None yet
2 participants
@yaronyg
Member

yaronyg commented Mar 14, 2016

Take a quick pass to see which files we want to maintain over the transition

@yaronyg yaronyg self-assigned this Mar 14, 2016

@yaronyg yaronyg added this to the New Infra milestone Mar 14, 2016

@yaronyg yaronyg added 0 - Icebox and removed 0 - Icebox labels Mar 14, 2016

@yaronyg yaronyg changed the title from Move us official over to Next Generation to Move us officially over to Next Generation Mar 14, 2016

@yaronyg yaronyg removed their assignment Jul 15, 2016

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Aug 5, 2016

Member

For boring historical reasons (which honestly weren't terribly compelling) we have our old december code co-existing with our vNext code. Once #811 passes and before we check in #740 we need to make this change (hopefully along with @artemjackson's work on #759).

  • Delete the doc directory, it's all out of date
  • Do we ever use test/TestServer/test/testTestServer.js for anything? Is there anything in there worth saving?
  • Since you will eventually own this code anyway is there anything in test/TestServer/PerfTestConfig.js, PerfTestFramework.js, TestPerfTestConfig.js and TestPerfTestConfig2.js worth saving?
  • Please move test/www/jxcore/bv_tests/disabled/identityExchangeTestUtils.js, testConnectionTable.js, testIdentityExchange.js, testIdentityExchangeendpoint.js, testIdentityExchangeUtils.js, testLargerHashStateMachine.js, testLiveIdentityExchange.js and testSmallerHashStateMachine.js to a new directory called test/www/jscore/bv_tests/identityExchangeTests. They should still be disabled but it's my job to eventually get them working again. Once you move those files please delete test/www/bv_Tests/disabled.
  • Delete the files in test/www/jxcore/lib that we aren't actually using anymore.
  • Figure out which of the meta_tests are still doing anything useful. Take a look at the testPerf* files in particular. Decide what in there you want to keep for your future perf work.
  • Go through test/www/jxcore/perf_tests and decide what is worth saving, delete everything else
  • Take a look at test/www/jxcore/PerfTest_app.js and decide if it's worth saving
  • Can we just delete thali/tcpmultiplexjs? thalicryptomanager.js? thaliemitter.js? I think we still use validations.js but can we find a better place to put it than at the Thali root?
  • I like having the bulk of our logic inside of a folder instead of sitting at the Thali root. So I don't actually want to get rid of the NextGeneration folder. What I would like to do is find any *.js files at the Thali root that we still need (with the exception of installCordovaPlugin.js which I think should be at the Thali root) and move them into NextGeneration (e.g. thaliLogger and validations) and then change the name of NextGeneration to something more meaningful like "Runtime".

Please make sure to use 'git mv' when moving or renaming things. And yes as you move stuff around all the paths have to be fixed up. I'd suggest using an IDE like WebStorm or IntelliJ that can figure a lot of this out for you automatically so you don't have to chase everything down.

My other suggestion is that we will do #759 once this bug is done. Which again won't happen until #811 is checked in to vNext and you have finished #507 and we have merged #507 and #811 into vNext_yarong_417_1 (e.g. #740).

Although I wonder how much easier this might be if we did #759 first? But I suspect we would have to do a lot of surgery on a lot of files before we saw any benefit and we don't have time for that right now. But talk to @artemjackson about it.

Member

yaronyg commented Aug 5, 2016

For boring historical reasons (which honestly weren't terribly compelling) we have our old december code co-existing with our vNext code. Once #811 passes and before we check in #740 we need to make this change (hopefully along with @artemjackson's work on #759).

  • Delete the doc directory, it's all out of date
  • Do we ever use test/TestServer/test/testTestServer.js for anything? Is there anything in there worth saving?
  • Since you will eventually own this code anyway is there anything in test/TestServer/PerfTestConfig.js, PerfTestFramework.js, TestPerfTestConfig.js and TestPerfTestConfig2.js worth saving?
  • Please move test/www/jxcore/bv_tests/disabled/identityExchangeTestUtils.js, testConnectionTable.js, testIdentityExchange.js, testIdentityExchangeendpoint.js, testIdentityExchangeUtils.js, testLargerHashStateMachine.js, testLiveIdentityExchange.js and testSmallerHashStateMachine.js to a new directory called test/www/jscore/bv_tests/identityExchangeTests. They should still be disabled but it's my job to eventually get them working again. Once you move those files please delete test/www/bv_Tests/disabled.
  • Delete the files in test/www/jxcore/lib that we aren't actually using anymore.
  • Figure out which of the meta_tests are still doing anything useful. Take a look at the testPerf* files in particular. Decide what in there you want to keep for your future perf work.
  • Go through test/www/jxcore/perf_tests and decide what is worth saving, delete everything else
  • Take a look at test/www/jxcore/PerfTest_app.js and decide if it's worth saving
  • Can we just delete thali/tcpmultiplexjs? thalicryptomanager.js? thaliemitter.js? I think we still use validations.js but can we find a better place to put it than at the Thali root?
  • I like having the bulk of our logic inside of a folder instead of sitting at the Thali root. So I don't actually want to get rid of the NextGeneration folder. What I would like to do is find any *.js files at the Thali root that we still need (with the exception of installCordovaPlugin.js which I think should be at the Thali root) and move them into NextGeneration (e.g. thaliLogger and validations) and then change the name of NextGeneration to something more meaningful like "Runtime".

Please make sure to use 'git mv' when moving or renaming things. And yes as you move stuff around all the paths have to be fixed up. I'd suggest using an IDE like WebStorm or IntelliJ that can figure a lot of this out for you automatically so you don't have to chase everything down.

My other suggestion is that we will do #759 once this bug is done. Which again won't happen until #811 is checked in to vNext and you have finished #507 and we have merged #507 and #811 into vNext_yarong_417_1 (e.g. #740).

Although I wonder how much easier this might be if we did #759 first? But I suspect we would have to do a lot of surgery on a lot of files before we saw any benefit and we don't have time for that right now. But talk to @artemjackson about it.

@yaronyg yaronyg added 3 - Working and removed 2 - Ready labels Aug 8, 2016

@yaronyg yaronyg added 3 - Working and removed 2 - Ready labels Aug 15, 2016

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Aug 16, 2016

Member

About 20% done.

Member

yaronyg commented Aug 16, 2016

About 20% done.

@andrew-aladev

This comment has been minimized.

Show comment
Hide comment
@andrew-aladev

andrew-aladev Aug 17, 2016

Contributor

I like having the bulk of our logic inside of a folder instead of sitting at the Thali root. So I don't actually want to get rid of the NextGeneration folder. What I would like to do is find any *.js files at the Thali root that we still need (with the exception of installCordovaPlugin.js which I think should be at the Thali root) and move them into NextGeneration (e.g. thaliLogger and validations) and then change the name of NextGeneration to something more meaningful like "Runtime".

I made an exception for:

  1. installCordovaPlugin.js and install directory (used in installCordovaPlugin.js)
  2. package.json and conf.json (used in package.json)

Can we just delete thali/tcpmultiplexjs? thalicryptomanager.js? thaliemitter.js? I think we still use validations.js but can we find a better place to put it than at the Thali root?

We are still using validations and thaliEmitter. thaliEmitter is used in identityExchangeTests. I saved it to Runtime/utils directory.

Please move test/www/jxcore/bv_tests/disabled/identityExchangeTestUtils.js, testConnectionTable.js, testIdentityExchange.js, testIdentityExchangeendpoint.js, testIdentityExchangeUtils.js, testLargerHashStateMachine.js, testLiveIdentityExchange.js and testSmallerHashStateMachine.js to a new directory called test/www/jscore/bv_tests/identityExchangeTests. They should still be disabled but it's my job to eventually get them working again. Once you move those files please delete test/www/bv_Tests/disabled.

I moved testThaliEmitter to bv_tests. thaliEmitter is used in identityExchangeTests and its test work fine.

Delete the files in test/www/jxcore/lib that we aren't actually using anymore.

All files are used in bv_tests.

Do we ever use test/TestServer/test/testTestServer.js for anything? Is there anything in there worth saving?

Yes, this test was just a bit outdated. I've fixed it. We can run it with jx test/testTestServer.js

Contributor

andrew-aladev commented Aug 17, 2016

I like having the bulk of our logic inside of a folder instead of sitting at the Thali root. So I don't actually want to get rid of the NextGeneration folder. What I would like to do is find any *.js files at the Thali root that we still need (with the exception of installCordovaPlugin.js which I think should be at the Thali root) and move them into NextGeneration (e.g. thaliLogger and validations) and then change the name of NextGeneration to something more meaningful like "Runtime".

I made an exception for:

  1. installCordovaPlugin.js and install directory (used in installCordovaPlugin.js)
  2. package.json and conf.json (used in package.json)

Can we just delete thali/tcpmultiplexjs? thalicryptomanager.js? thaliemitter.js? I think we still use validations.js but can we find a better place to put it than at the Thali root?

We are still using validations and thaliEmitter. thaliEmitter is used in identityExchangeTests. I saved it to Runtime/utils directory.

Please move test/www/jxcore/bv_tests/disabled/identityExchangeTestUtils.js, testConnectionTable.js, testIdentityExchange.js, testIdentityExchangeendpoint.js, testIdentityExchangeUtils.js, testLargerHashStateMachine.js, testLiveIdentityExchange.js and testSmallerHashStateMachine.js to a new directory called test/www/jscore/bv_tests/identityExchangeTests. They should still be disabled but it's my job to eventually get them working again. Once you move those files please delete test/www/bv_Tests/disabled.

I moved testThaliEmitter to bv_tests. thaliEmitter is used in identityExchangeTests and its test work fine.

Delete the files in test/www/jxcore/lib that we aren't actually using anymore.

All files are used in bv_tests.

Do we ever use test/TestServer/test/testTestServer.js for anything? Is there anything in there worth saving?

Yes, this test was just a bit outdated. I've fixed it. We can run it with jx test/testTestServer.js

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Aug 17, 2016

Member

Should be done today.

Member

yaronyg commented Aug 17, 2016

Should be done today.

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Aug 18, 2016

Member

Still working on 811 so that is blocking this.

Member

yaronyg commented Aug 18, 2016

Still working on 811 so that is blocking this.

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Aug 19, 2016

Member

A few more hours of work to do so might slip to Monday.

Member

yaronyg commented Aug 19, 2016

A few more hours of work to do so might slip to Monday.

@andrew-aladev

This comment has been minimized.

Show comment
Hide comment
@andrew-aladev

andrew-aladev Aug 22, 2016

Contributor

Since you will eventually own this code anyway is there anything in test/TestServer/PerfTestConfig.js, PerfTestFramework.js, TestPerfTestConfig.js and TestPerfTestConfig2.js worth saving?

I've moved TestPerfTestConfig* to the test/config dir. jx test/testTestServer.js works fine. PerfTestConfig.js is an analog for UnitTestConfig.js, PerfTestFramework.js -> UnitTestFramework.js. These are complex things, but it looks like it should exist. I will investigate it in the next task about creating a new test.

Figure out which of the meta_tests are still doing anything useful. Take a look at the testPerf* files in particular. Decide what in there you want to keep for your future perf work.

We can implement good tests for lib/testUtils in testTestUtils.js and for thali/install in testInstall.js in future.
Other tests are related to existing perf tests frameworks. We need to investigate these frameworks before deleting these tests.

Take a look at test/www/jxcore/PerfTest_app.js and decide if it's worth saving

I think this can be saved. It was used instead of UnitTest_app.js for perf tests.

Go through test/www/jxcore/perf_tests and decide what is worth saving, delete everything else

I don't think we should delete BluetoothConnectionLimits.js. It requires investigation.
testSendData.js and testFindPeers.js are used in TestServer/test/testTestServer.js and work fine. SendDataConnector.js and SendDataTCPServer.js are used in testSendData.js.

testReConnect.js and its deps: ReConnectConnector.js and ReConnectTCPServer.js could be deleted. But this test is a thing that we should rewrite, so it will be deleted after new tests implementation.

I've removed testNewFindPeers.js testNewSendData.js. It looks like these tests are old abandoned copies of testFindPeers.js testSendData.js

Contributor

andrew-aladev commented Aug 22, 2016

Since you will eventually own this code anyway is there anything in test/TestServer/PerfTestConfig.js, PerfTestFramework.js, TestPerfTestConfig.js and TestPerfTestConfig2.js worth saving?

I've moved TestPerfTestConfig* to the test/config dir. jx test/testTestServer.js works fine. PerfTestConfig.js is an analog for UnitTestConfig.js, PerfTestFramework.js -> UnitTestFramework.js. These are complex things, but it looks like it should exist. I will investigate it in the next task about creating a new test.

Figure out which of the meta_tests are still doing anything useful. Take a look at the testPerf* files in particular. Decide what in there you want to keep for your future perf work.

We can implement good tests for lib/testUtils in testTestUtils.js and for thali/install in testInstall.js in future.
Other tests are related to existing perf tests frameworks. We need to investigate these frameworks before deleting these tests.

Take a look at test/www/jxcore/PerfTest_app.js and decide if it's worth saving

I think this can be saved. It was used instead of UnitTest_app.js for perf tests.

Go through test/www/jxcore/perf_tests and decide what is worth saving, delete everything else

I don't think we should delete BluetoothConnectionLimits.js. It requires investigation.
testSendData.js and testFindPeers.js are used in TestServer/test/testTestServer.js and work fine. SendDataConnector.js and SendDataTCPServer.js are used in testSendData.js.

testReConnect.js and its deps: ReConnectConnector.js and ReConnectTCPServer.js could be deleted. But this test is a thing that we should rewrite, so it will be deleted after new tests implementation.

I've removed testNewFindPeers.js testNewSendData.js. It looks like these tests are old abandoned copies of testFindPeers.js testSendData.js

@yaronyg yaronyg assigned yaronyg and unassigned andrew-aladev Aug 22, 2016

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Aug 22, 2016

Member

O.k. this looks reasonable to me. Just please file the issues to make sure we actually follow up on the various things you identified as needing to be investigated/re-written.

Member

yaronyg commented Aug 22, 2016

O.k. this looks reasonable to me. Just please file the issues to make sure we actually follow up on the various things you identified as needing to be investigated/re-written.

@yaronyg

This comment has been minimized.

Show comment
Hide comment
@yaronyg

yaronyg Aug 26, 2016

Member

We took a run at it, it kind of blew up. So we'll try again later when we have vNext stabilized and then we will have everyone shut out of vNext until we get this bug done.

Member

yaronyg commented Aug 26, 2016

We took a run at it, it kind of blew up. So we'll try again later when we have vNext stabilized and then we will have everyone shut out of vNext until we get this bug done.

@andrew-aladev andrew-aladev added estimate - 2 and removed 4 - Done labels Sep 2, 2016

@yaronyg yaronyg added enhancement Node and removed 1 - Backlog labels Oct 6, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment