Office furniture hasn’t changed in a while--about 79 years, in fact

Branch

If you are curious to see the first commit that has been done to some preferred GitHub repository of yours, then you do not need to spend minutes just to navigate to that particular commit. You can now see it using a new Chrome plugin. You may be curious to see the first commit that you have done for a particular project that you have started, or that your colleagues have done so that you can feel a bit of nostalgy what included that commit. You may also be curious to find out this for many other projects as well. This new Chrome plugin is really easy to use and can save you a lot of time from having to navigate and find the first commit of Github projects. All you have to do is install it and in then you can go to the Github page of the project that you want and go to its first commit using the new item Github commit that will be added in your right-click menu. This can be really handy when you are trying to simply see how others started their git projects. This is an that was authored by the famous open source developer , who is also the author of many other open source projects and plugins. He is the initiator of the project which literally brings in new Chrome tabs the most starred Github projects. Chrome plugin open source project Kamran Ahmed Githunt

See the first commit of a GitHub repository in a matter of seconds

Authors:
(1) Xian Liu, Snap Inc., CUHK with Work done during an internship at Snap Inc.;
(2) Jian Ren, Snap Inc. with Corresponding author: jren@snapchat.com;
(3) Aliaksandr Siarohin, Snap Inc.;
(4) Ivan Skorokhodov, Snap Inc.;
(5) Yanyu Li, Snap Inc.;
(6) Dahua Lin, CUHK;
(7) Xihui Liu, HKU;
(8) Ziwei Liu, NTU;
(9) Sergey Tulyakov, Snap Inc. Table of Links Abstract and 1 Introduction 2 Related Work 3 Our Approach and 3.1 Preliminaries and Problem Setting 3.2 Latent Structural Diffusion Model 3.3 Structure-Guided Refiner 4 Human Verse Dataset 5 Experiments 5.1 Main Results 5.2 Ablation Study 6 Discussion and References A Appendix and A.1 Additional Quantitative Results A.2 More Implementation Details and A.3 More Ablation Study Results A.4 More User Study Details A.5 Impact of Random Seed and Model Robustness and A.6 Boarder Impact and Ethical Consideration A.7 More Comparison Results and A.8 Additional Qualitative Results A.9 Licenses 5.2 ABLATION STUDY Simultaneous Denoise with Expert Branch. We explore whether latent structural diffusion model helps, and how many layers to replicate in the structural expert branches: 1) Denoise RGB, that only learns to denoise an image. 2) Denoise RGB + Depth, which also predicts depth. 3) Half DownBlock & UpBlock. We replicate half of the first DownBlock and the last UpBlock, which contains one down/up-sample ResBlock and one AttnBlock. 4) Two DownBlocks & UpBlocks, where we copy the first two DownBlocks and the last two UpBlocks. The results are shown in Tab. 2 (top), which prove that the joint learning of image appearance, spatial relationship, and geometry is beneficial. We also find that while fewer replicate layers give more spatially aligned results, the per-branch parameters are insufficient to capture distributions of each modality. In contrast, excessive replicate layers lead to less feature fusion across different targets, which fails to complement to each other branches. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Xian Liu, Snap Inc., CUHK with Work done during an internship at Snap Inc.; (2) Jian Ren, Snap Inc. with Corresponding author: jren@snapchat.com; (3) Aliaksandr Siarohin, Snap Inc.; (4) Ivan Skorokhodov, Snap Inc.; (5) Yanyu Li, Snap Inc.; (6) Dahua Lin, CUHK; (7) Xihui Liu, HKU; (8) Ziwei Liu, NTU; (9) Sergey Tulyakov, Snap Inc. Authors: Authors: (1) Xian Liu, Snap Inc., CUHK with Work done during an internship at Snap Inc.; (2) Jian Ren, Snap Inc. with Corresponding author: jren@snapchat.com; (3) Aliaksandr Siarohin, Snap Inc.; (4) Ivan Skorokhodov, Snap Inc.; (5) Yanyu Li, Snap Inc.; (6) Dahua Lin, CUHK; (7) Xihui Liu, HKU; (8) Ziwei Liu, NTU; (9) Sergey Tulyakov, Snap Inc. Table of Links Abstract and 1 Introduction Abstract and 1 Introduction 2 Related Work 2 Related Work 3 Our Approach and 3.1 Preliminaries and Problem Setting 3 Our Approach and 3.1 Preliminaries and Problem Setting 3.2 Latent Structural Diffusion Model 3.2 Latent Structural Diffusion Model 3.3 Structure-Guided Refiner 3.3 Structure-Guided Refiner 4 Human Verse Dataset 4 Human Verse Dataset 5 Experiments 5 Experiments 5.1 Main Results 5.1 Main Results 5.2 Ablation Study 5.2 Ablation Study 6 Discussion and References 6 Discussion and References A Appendix and A.1 Additional Quantitative Results A Appendix and A.1 Additional Quantitative Results A.2 More Implementation Details and A.3 More Ablation Study Results A.2 More Implementation Details and A.3 More Ablation Study Results A.4 More User Study Details A.4 More User Study Details A.5 Impact of Random Seed and Model Robustness and A.6 Boarder Impact and Ethical Consideration A.5 Impact of Random Seed and Model Robustness and A.6 Boarder Impact and Ethical Consideration A.7 More Comparison Results and A.8 Additional Qualitative Results A.7 More Comparison Results and A.8 Additional Qualitative Results A.9 Licenses A.9 Licenses 5.2 ABLATION STUDY Simultaneous Denoise with Expert Branch. We explore whether latent structural diffusion model helps, and how many layers to replicate in the structural expert branches: 1) Denoise RGB, that only learns to denoise an image. 2) Denoise RGB + Depth, which also predicts depth. 3) Half DownBlock & UpBlock. We replicate half of the first DownBlock and the last UpBlock, which contains one down/up-sample ResBlock and one AttnBlock. 4) Two DownBlocks & UpBlocks, where we copy the first two DownBlocks and the last two UpBlocks. The results are shown in Tab. 2 (top), which prove that the joint learning of image appearance, spatial relationship, and geometry is beneficial. We also find that while fewer replicate layers give more spatially aligned results, the per-branch parameters are insufficient to capture distributions of each modality. In contrast, excessive replicate layers lead to less feature fusion across different targets, which fails to complement to each other branches. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

HyperHuman Ablation Study: Optimal Expert Branch Design for Improved Image Generation

Author:
(1) Hiranmoy Pal, National Institute of Technology Rourkela, Odisha-769008, India. Table of Links Introduction, Acknowledgments and References Quantum state transfer plays an important role in quantum information processing. The evolution of certain pair states in a quantum network with Heisenberg XY Hamiltonian depends only on the local structure of the network, and it remains unchanged even if the global structure is altered. All graphs with high-fidelity vertex state transfer may be considered as isomorphic branches of the graph underlying a large quantum network to exhibit high-fidelity pair state transfer. Among other graphs, one may construct infinite family of trees admitting perfect pair state transfer. ACKNOWLEDGMENTS The research is funded by Science and Engineering Research Board (Project: SRG/2021/000522). References [1] E. Farhi and S. Gutmann, Quantum computation and decision trees, Phys. Rev. A 58, 915 (1998). [2] M. Christandl, N. Datta, A. Ekert, and A. J. Landahl, Perfect state transfer in quantum spin networks, Phys. Rev. Lett. 92, 187902 (2004). [3] S. Bose, A. Casaccino, S. Mancini, and S. Severini, Communication in XYZ all-to-all quantum networks with a missing link, Int. J. Quantum Inf. 7, 713 (2009). [4] H. Pal, Laplacian state transfer on graphs with an edge perturbation between twin vertices, Discrete Math. 345, 112872 (2022). [5] S. Bose, Quantum communication through an unmodulated spin chain, Phys. Rev. Lett. 91, 207901 (2003). [6] Q. Chen and C. Godsil, Pair state transfer, Quantum Inf. Process. 19, 321 (2020). [7] M. Baˇsi´c, Characterization of quantum circulant networks having perfect state transfer, Quantum Inf. Process. 12, 345 (2013). [8] H. Pal and B. Bhattacharjya, Pretty good state transfer on circulant graphs, Electron. J. Combin. 24, Paper No. 2.23, 13 (2017). [9] C. Godsil, S. Kirkland, S. Severini, and J. Smith, Number-theoretic nature of communication in quantum spin systems, Phys. Rev. Lett. 109, 050502 (2012). [10] D. Cvetkovi´c, P. Rowlinson, and S. Simi´c, An introduction to the theory of graph spectra, London Mathematical Society Student Texts, Vol. 75 (Cambridge University Press, Cambridge, 2010) pp. xii+364. This paper is available on arxiv under CC BY 4.0 DEED license. Author: (1) Hiranmoy Pal, National Institute of Technology Rourkela, Odisha-769008, India. Author: Author: (1) Hiranmoy Pal, National Institute of Technology Rourkela, Odisha-769008, India. Table of Links Introduction, Acknowledgments and References Introduction, Acknowledgments and References Quantum state transfer plays an important role in quantum information processing. The evolution of certain pair states in a quantum network with Heisenberg XY Hamiltonian depends only on the local structure of the network, and it remains unchanged even if the global structure is altered. All graphs with high-fidelity vertex state transfer may be considered as isomorphic branches of the graph underlying a large quantum network to exhibit high-fidelity pair state transfer. Among other graphs, one may construct infinite family of trees admitting perfect pair state transfer. ACKNOWLEDGMENTS The research is funded by Science and Engineering Research Board (Project: SRG/2021/000522). References [1] E. Farhi and S. Gutmann, Quantum computation and decision trees, Phys. Rev. A 58, 915 (1998). [2] M. Christandl, N. Datta, A. Ekert, and A. J. Landahl, Perfect state transfer in quantum spin networks, Phys. Rev. Lett. 92, 187902 (2004). [3] S. Bose, A. Casaccino, S. Mancini, and S. Severini, Communication in XYZ all-to-all quantum networks with a missing link, Int. J. Quantum Inf. 7, 713 (2009). [4] H. Pal, Laplacian state transfer on graphs with an edge perturbation between twin vertices, Discrete Math. 345, 112872 (2022). [5] S. Bose, Quantum communication through an unmodulated spin chain, Phys. Rev. Lett. 91, 207901 (2003). [6] Q. Chen and C. Godsil, Pair state transfer, Quantum Inf. Process. 19, 321 (2020). [7] M. Baˇsi´c, Characterization of quantum circulant networks having perfect state transfer, Quantum Inf. Process. 12, 345 (2013). [8] H. Pal and B. Bhattacharjya, Pretty good state transfer on circulant graphs, Electron. J. Combin. 24, Paper No. 2.23, 13 (2017). [9] C. Godsil, S. Kirkland, S. Severini, and J. Smith, Number-theoretic nature of communication in quantum spin systems, Phys. Rev. Lett. 109, 050502 (2012). [10] D. Cvetkovi´c, P. Rowlinson, and S. Simi´c, An introduction to the theory of graph spectra, London Mathematical Society Student Texts, Vol. 75 (Cambridge University Press, Cambridge, 2010) pp. xii+364. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

Quantum Pair State Transfer on Isomorphic Branches

In the previous article in this series, we looked at how we could automate deploys to Heroku using Heroku Flow for our CI/CD. That setup had two Heroku apps for staging and production but only used a single main branch. The staging app was automatically deployed when you committed to the main branch, and the production app was manually deployed by clicking the “Promote to production” button in the Heroku pipeline. That strategy assumes that you’re doing “trunk-based development,” in which you commit to a single main branch in your code repo. However, some engineering teams still follow a branching strategy called Gitflow, which involves using a dev branch and a main branch. Feature branches are merged into the dev branch to deploy code to a staging environment and on a regular cadence, the dev branch is merged into the main branch to release the code to the production environment. In this article, we’ll consider how we can configure Heroku Flow to meet our CI/CD needs when following the Gitflow branching strategy. We’ll use our Heroku Pipeline to deploy our app to our staging environment when we push to the dev branch and deploy our app to our production environment when we push it to the main branch. Ready to go with the flow? Getting Started If you’d like to follow along throughout this tutorial, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here, and you can create a GitHub account here. The demo app shown in this article is deployed to Heroku, and the code is hosted on GitHub. Running Our App Locally You can run the app locally by forking the repo in GitHub, installing dependencies, and running the start command. In your terminal, do the following after forking the repo: $ cd heroku-flow-gitflow-demo
$ npm install
$ npm start After starting the app, visit http://localhost:5001/ in your browser, and you’ll see the app running locally: Creating Our Heroku Pipeline Now that we have the app running locally let’s get it deployed to Heroku so that it can be accessed anywhere, not just on your machine. We’re going to create a Heroku pipeline that includes two apps: a staging app and a production app. To create a new Heroku pipeline, navigate to your Heroku dashboard, click the “New” button in the top-right corner of the screen, and then choose “Create new pipeline” from the menu. In the dialog that appears, give your pipeline a name, choose an owner (yourself), and connect your GitHub repo. If this is your first time connecting your GitHub account to Heroku, a second popup will appear in which you can confirm giving Heroku access to GitHub. After connecting to GitHub, click “Create pipeline” to finish the process. With that, you’ve created a Heroku pipeline. Nice work! Creating Our Staging and Production Apps As we mentioned, we’ll use two environments for our app: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. The production environment is where code is released to actual users. Let’s add a staging app and a production app to our pipeline. Both of these apps will be based on the same GitHub repo. To add a staging app, click the “Add app” button in the Staging section. Next, click “Create new app” to open a side panel. In the side panel, give your app a name, choose an owner (yourself), and choose a region (I left mine in the United States). Then click “Create app” to confirm your changes. Congrats, you’ve just created a staging app! Now let’s do the same thing, but this time for our production app. When you’re done configuring your production app, you should see both apps in your pipeline: Configuring Automatic Deploys We want our app to be deployed to our staging environment any time we commit to our repo’s dev branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. In the dialog that appears, make sure the dev branch is targeted, and check the box to “Wait for CI to pass before deploy.” In a later step, we’ll configure Heroku CI so that we can run tests in a CI pipeline. We don’t want to deploy our app to our staging environment unless CI is passing. Now let’s do the same thing for the production app, but this time choosing to deploy our production app whenever we commit code to the main branch. Enabling Heroku CI If we’re going to require CI to pass, we had better have something configured for CI! Navigate to the “Tests” tab and then click the “Enable Heroku CI” button. Our demo app is built with Node and runs unit tests with Jest. The tests are run through the npm test script. Heroku CI allows you to configure more complicated CI setups using an app.json file, but in our case because the test setup is fairly basic, Heroku CI can figure out which command to run without any additional configuration on our part. Pretty neat! Enabling Review Apps For the last part of our pipeline setup, let’s enable review apps. Review apps are temporary apps which get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to manually review your changes. With a review app in place, the reviewer can simply open the review app rather than having to pull down the code onto their machine to run the app locally. To enable review apps, click the “Enable Review Apps” button on the pipeline page. In the dialog that appears, check all three boxes. The first box enables review apps to be automatically created for each PR.
The second box ensures that the review app isn’t created until CI passes.
The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. When you’re done with your configuration, click “Enable Review Apps” to finalize your changes. Seeing It All in Action Alright, you made it! Let’s review what we’ve done so far. We created a Heroku pipeline.
We created a staging app and a production app for that pipeline.
We enabled automatic deploys from the dev branch to our staging app.
We enabled automatic deploys from the main branch to our production app.
We enabled Heroku CI to run tests for every PR.
We enabled the creation of Heroku review apps for every PR. Now, let’s see it all in action! Create a feature branch off of your dev branch with any code change you’d like, and then use that to create a PR in GitHub to merge that feature branch into dev. I made a very minor UI change, updating the heading text from “Heroku Flow Gitflow Demo” to “Heroku Flow Gitflow Branching”. Right after the PR is created, you’ll note that a new “check” gets created in GitHub for the Heroku CI pipeline. You can view the test output back in Heroku on your Tests tab: After the CI pipeline passes, you’ll note that another piece of info gets appended to your PR in GitHub. The review app is deployed, and GitHub shows a link to the review app. Click the “View deployment” button, and you’ll see a temporary Heroku app with your code changes. You can also find a link to the review app in your Heroku pipeline: Let’s assume that you’ve gotten a code review and that everything looks good. It’s time to merge your PR. After you’ve merged your PR, look back at the Heroku pipeline. You’ll see that Heroku automatically deployed the staging app since new code was committed to the dev branch. At this point in the software development lifecycle, there might be some final QA or acceptance testing of the app in the staging environment. Let’s assume that everything still looks good and that you’re ready to release this change to your users in production. You can create another PR to merge the dev branch into the main branch, or you can do this from your terminal by checking out the main branch and then running git merge dev and git push. Once you’ve committed these changes to the main branch, look at your Heroku pipeline again, and you’ll see that the production app was automatically deployed. And with that, your changes are now in production for all your users to see. Way to go! Conclusion If you’ve followed along this far, give yourself a pat on the back. Walking through these steps, we’ve configured everything we need for an enterprise-ready CI/CD solution for a team using the Gitflow branching strategy and multiple environments. It doesn’t matter if you prefer trunk-based development or Gitflow as your branching strategy — Heroku Flow can support either. Now not only can you host your apps on Heroku, but you can set up all of your CI/CD infrastructure on Heroku’s platform as well. In the previous article in this series, we looked at how we could automate deploys to Heroku using Heroku Flow for our CI/CD . That setup had two Heroku apps for staging and production but only used a single main branch. The staging app was automatically deployed when you committed to the main branch, and the production app was manually deployed by clicking the “Promote to production” button in the Heroku pipeline. using Heroku Flow for our CI/CD main main That strategy assumes that you’re doing “ trunk-based development ,” in which you commit to a single main branch in your code repo. trunk-based development main However, some engineering teams still follow a branching strategy called Gitflow , which involves using a dev branch and a main branch. Feature branches are merged into the dev branch to deploy code to a staging environment and on a regular cadence, the dev branch is merged into the main branch to release the code to the production environment. Gitflow dev main dev dev main In this article, we’ll consider how we can configure Heroku Flow to meet our CI/CD needs when following the Gitflow branching strategy. We’ll use our Heroku Pipeline to deploy our app to our staging environment when we push to the dev branch and deploy our app to our production environment when we push it to the main branch. Heroku Flow dev main Ready to go with the flow? Getting Started If you’d like to follow along throughout this tutorial, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here , and you can create a GitHub account here . create a Heroku account here create a GitHub account here The demo app shown in this article is deployed to Heroku, and the code is hosted on GitHub . the code is hosted on GitHub Running Our App Locally You can run the app locally by forking the repo in GitHub, installing dependencies, and running the start command. In your terminal, do the following after forking the repo: $ cd heroku-flow-gitflow-demo
$ npm install
$ npm start $ cd heroku-flow-gitflow-demo
$ npm install
$ npm start After starting the app, visit http://localhost:5001/ in your browser, and you’ll see the app running locally: http://localhost:5001/ Creating Our Heroku Pipeline Now that we have the app running locally let’s get it deployed to Heroku so that it can be accessed anywhere, not just on your machine. We’re going to create a Heroku pipeline that includes two apps: a staging app and a production app. To create a new Heroku pipeline, navigate to your Heroku dashboard, click the “New” button in the top-right corner of the screen, and then choose “Create new pipeline” from the menu. In the dialog that appears, give your pipeline a name, choose an owner (yourself), and connect your GitHub repo. If this is your first time connecting your GitHub account to Heroku, a second popup will appear in which you can confirm giving Heroku access to GitHub. After connecting to GitHub, click “Create pipeline” to finish the process. With that, you’ve created a Heroku pipeline. Nice work! Creating Our Staging and Production Apps As we mentioned, we’ll use two environments for our app: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. The production environment is where code is released to actual users. Let’s add a staging app and a production app to our pipeline. Both of these apps will be based on the same GitHub repo. To add a staging app, click the “Add app” button in the Staging section. Next, click “Create new app” to open a side panel. In the side panel, give your app a name, choose an owner (yourself), and choose a region (I left mine in the United States). Then click “Create app” to confirm your changes. Congrats, you’ve just created a staging app! Now let’s do the same thing, but this time for our production app. When you’re done configuring your production app, you should see both apps in your pipeline: Configuring Automatic Deploys We want our app to be deployed to our staging environment any time we commit to our repo’s dev branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. dev In the dialog that appears, make sure the dev branch is targeted, and check the box to “Wait for CI to pass before deploy.” In a later step, we’ll configure Heroku CI so that we can run tests in a CI pipeline. We don’t want to deploy our app to our staging environment unless CI is passing. dev Now let’s do the same thing for the production app, but this time choosing to deploy our production app whenever we commit code to the main branch. main Enabling Heroku CI If we’re going to require CI to pass, we had better have something configured for CI! Navigate to the “Tests” tab and then click the “Enable Heroku CI” button. Our demo app is built with Node and runs unit tests with Jest. The tests are run through the npm test script. Heroku CI allows you to configure more complicated CI setups using an app.json file, but in our case because the test setup is fairly basic, Heroku CI can figure out which command to run without any additional configuration on our part. Pretty neat! npm test app.json Enabling Review Apps For the last part of our pipeline setup, let’s enable review apps. Review apps are temporary apps which get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to manually review your changes. With a review app in place, the reviewer can simply open the review app rather than having to pull down the code onto their machine to run the app locally. To enable review apps, click the “Enable Review Apps” button on the pipeline page. In the dialog that appears, check all three boxes. The first box enables review apps to be automatically created for each PR. The second box ensures that the review app isn’t created until CI passes. The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. The first box enables review apps to be automatically created for each PR. The second box ensures that the review app isn’t created until CI passes. The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. When you’re done with your configuration, click “Enable Review Apps” to finalize your changes. Seeing It All in Action Alright, you made it! Let’s review what we’ve done so far. We created a Heroku pipeline. We created a staging app and a production app for that pipeline. We enabled automatic deploys from the dev branch to our staging app. We enabled automatic deploys from the main branch to our production app. We enabled Heroku CI to run tests for every PR. We enabled the creation of Heroku review apps for every PR. We created a Heroku pipeline. We created a staging app and a production app for that pipeline. We enabled automatic deploys from the dev branch to our staging app. dev We enabled automatic deploys from the main branch to our production app. main We enabled Heroku CI to run tests for every PR. We enabled the creation of Heroku review apps for every PR. Now, let’s see it all in action! Create a feature branch off of your dev branch with any code change you’d like, and then use that to create a PR in GitHub to merge that feature branch into dev . I made a very minor UI change, updating the heading text from “Heroku Flow Gitflow Demo” to “Heroku Flow Gitflow Branching”. dev dev Right after the PR is created, you’ll note that a new “check” gets created in GitHub for the Heroku CI pipeline. You can view the test output back in Heroku on your Tests tab: After the CI pipeline passes, you’ll note that another piece of info gets appended to your PR in GitHub. The review app is deployed, and GitHub shows a link to the review app. Click the “View deployment” button, and you’ll see a temporary Heroku app with your code changes. You can also find a link to the review app in your Heroku pipeline: Let’s assume that you’ve gotten a code review and that everything looks good. It’s time to merge your PR. After you’ve merged your PR, look back at the Heroku pipeline. You’ll see that Heroku automatically deployed the staging app since new code was committed to the dev branch. dev At this point in the software development lifecycle, there might be some final QA or acceptance testing of the app in the staging environment. Let’s assume that everything still looks good and that you’re ready to release this change to your users in production. You can create another PR to merge the dev branch into the main branch, or you can do this from your terminal by checking out the main branch and then running git merge dev and git push . dev main main git merge dev git push Once you’ve committed these changes to the main branch, look at your Heroku pipeline again, and you’ll see that the production app was automatically deployed. main And with that, your changes are now in production for all your users to see. Way to go! Conclusion If you’ve followed along this far, give yourself a pat on the back. Walking through these steps, we’ve configured everything we need for an enterprise-ready CI/CD solution for a team using the Gitflow branching strategy and multiple environments. It doesn’t matter if you prefer trunk-based development or Gitflow as your branching strategy — Heroku Flow can support either. Now not only can you host your apps on Heroku, but you can set up all of your CI/CD infrastructure on Heroku’s platform as well.

Go With the CI/CD Flow: Using Heroku Flow With Gitflow Branching

Unlocking IaC Part 5: What Is Git Branching?

This paper is available on arxiv under CC 4.0 license. Authors: (1) Vianney Brouard, ENS de Lyon, UMPA, CNRS UMR 5669, 46 All´ee d’Italie, 69364 Lyon Cedex 07, France; E-mail: vianney.brouard@ens-lyon.f. Table of Links Abstract & Introduction and presentation of the model Main results and biological interpretation First-order asymptotics of the mutant sub-populations for an infinite mono-directional grap First-order asymptotics of the mutant sub-populations for a general finite trait space (Theorem 2.1) Convergence for the stochastic exponents (Theorem 2.2) Acknowledgements & References Acknowledgements The author would like to thank H´el`ene Leman for inspiring and helpful discussions and feedback. References [1] Guillaume Achaz. Frequency spectrum neutrality tests: one for all and all for one. Genetics, 183(1):249–258, 2009. [2] Jochen Blath, Tobias Paul, and Andr´as T´obi´as. A stochastic adaptive dynamics model for bacterial populations with mutation, dormancy and transfer. ALEA, Lat. Am. J. Probab. Math. Stat., 20:313–357, 2023. [3] Anton Bovier, Loren Coquille, and Charline Smadi. Crossing a fitness valley as a metastable transition in a stochastic population model. The Annals of Applied Probability, 29(6):3541–3589, 2019. [4] Ivana Bozic and Martin A Nowak. Timing and heterogeneity of mutations associated with drug resistance in metastatic cancers. Proceedings of the National Academy of Sciences, 111(45):15964– 15968, 2014. [5] Nicolas Champagnat, Sylvie M´el´eard, and Viet Chi Tran. Stochastic analysis of emergence of evolutionary cyclic behavior in population dynamics with transfer. The Annals of Applied Probability, 31(4):1820–1867, 2021. [6] David Cheek and Tibor Antal. Genetic composition of an exponentially growing cell population. Stochastic Processes and their Applications, 2020. [7] David Cheek, Tibor Antal, et al. Mutation frequencies in a birth–death branching process. The Annals of Applied Probability, 28(6):3922–3947, 2018. [8] Loren Coquille, Anna Kraut, and Charline Smadi. Stochastic individual-based models with power law mutation rate on a general finite trait space. Electronic Journal of Probability, 26:1–37, 2021. [9] Alexander Davis, Ruli Gao, and Nicholas Navin. Tumor evolution: Linear, branching, neutral or punctuated? Biochimica et Biophysica Acta (BBA)-Reviews on Cancer, 1867(2):151–161, 2017. [10] Claude Dellacherie and Paul andr´e Meyer. Probabilit´es et Potentiel. Collection Enseignement des Sciences. Hermann, Paris, 1975. [11] Richard Durrett. Branching process models of cancer. Springer, 2015. [12] Richard Durrett and Stephen Moseley. Evolution of resistance and progression to disease during clonal expansion of cancer. Theoretical population biology, 77(1):42–48, 2010. [13] Rick Durrett and John Mayberry. Traveling waves of selective sweeps. The Annals of Applied Probability, 21(2):699–744, 2011. [14] Manuel Esser and Anna Kraut. A general multi-scale description of metastable adaptive motion across fitness valleys. arXiv preprint arXiv:2112.12675, 2021. [15] Jasmine Foo and Kevin Leder. Dynamics of cancer recurrence. The Annals of Applied Probability, 23(4):1437–1468, 2013. [16] Jasmine Gamblin, Sylvain Gandon, Fran¸cois Blanquart, and Amaury Lambert. Bottlenecks can constrain and channel evolutionary paths. Genetics, 224(2):iyad001, 2023. [17] Einar Bjarki Gunnarsson, Kevin Leder, and Jasmine Foo. Exact site frequency spectra of neutrally evolving tumors: A transition between power laws reveals a signature of cell viability. Theoretical population biology, 142:67–90, 2021. [18] Einar Bjarki Gunnarsson, Kevin Leder, and Xuanming Zhang. Limit theorems for the site frequency spectrum of neutral mutations in an exponentially growing population. arXiv preprint arXiv:2307.03346, 2023. [19] Agnes Hamon and Bernard Ycart. Statistics for the luria-delbr¨uck distribution. Electronic Journal of Statistics, 2012. [20] Siˆan Jones, Wei-dong Chen, Giovanni Parmigiani, Frank Diehl, Niko Beerenwinkel, Tibor Antal, Arne Traulsen, Martin A Nowak, Christopher Siegel, Victor E Velculescu, et al. Comparative lesion sequencing provides insights into tumor evolution. Proceedings of the National Academy of Sciences, 105(11):4283–4288, 2008. [21] Peter Keller and Tibor Antal. Mutant number distribution in an exponentially growing population. Journal of Statistical Mechanics: Theory and Experiment, 2015(1):P01011, 2015. [22] David G Kendall. Birth-and-death processes, and the theory of carcinogenesis. Biometrika, 47(1/2):13–21, 1960. [23] David A Kessler and Herbert Levine. Scaling solution in the large population limit of the general asymmetric stochastic luria–delbr¨uck evolution process. Journal of statistical physics, 158(4):783– 805, 2015. [24] Jean-Fran¸cois Le Gall et al. Brownian motion, martingales, and stochastic calculus, volume 274. Springer, 2016. [25] Douglas E Lea and Charles Alfred Coulson. The distribution of the numbers of mutants in bacterial populations. Journal of genetics, 49:264–285, 1949. [26] Shaoping Ling, Zheng Hu, Zuyu Yang, Fang Yang, Yawei Li, Pei Lin, Ke Chen, Lili Dong, Lihua Cao, Yong Tao, et al. Extremely high genetic diversity in a single tumor points to prevalence of non-darwinian cell evolution. Proceedings of the National Academy of Sciences, 112(47):E6496– E6505, 2015. [27] Salvador E Luria and Max Delbr¨uck. Mutations of bacteria from virus sensitivity to virus resistance. Genetics, 28(6):491, 1943. [28] Michael D Nicholson and Tibor Antal. Competing evolutionary paths in growing populations with applications to multidrug resistance. PLoS computational biology, 15(4):e1006866, 2019. [29] Michael D Nicholson, David Cheek, and Tibor Antal. Sequential mutations in exponentially growing populations. PLOS Computational Biology, 19(7):e1011289, 2023. [30] Tobias Paul. The canonical equation of adaptive dynamics in individual-based models with power law mutation rates, 2023. [31] Andrea Sottoriva, Haeyoun Kang, Zhicheng Ma, Trevor A Graham, Matthew P Salomon, Junsong Zhao, Paul Marjoram, Kimberly Siegmund, Michael F Press, Darryl Shibata, et al. A big bang model of human colorectal tumor growth. Nature genetics, 47(3):209–216, 2015. [32] Subramanian Venkatesan and Charles Swanton. Tumor evolutionary principles: how intratumor heterogeneity influences cancer treatment and outcome. American Society of Clinical Oncology Educational Book, 36:e141–e149, 2016. [33] Marc J Williams, Benjamin Werner, Chris P Barnes, Trevor A Graham, and Andrea Sottoriva. Identification of neutral tumor evolution across cancer types. Nature genetics, 48(3):238–244, 2016. [34] Kai Zeng, Yun-Xin Fu, Suhua Shi, and Chung-I Wu. Statistical tests for detecting positive selection by utilizing high-frequency variants. Genetics, 174(3):1431–1439, 2006.

Genetic Composition of Supercritical Branching Populations: Acknowledgements & References

This paper is available on arxiv under CC 4.0 license. Authors: (1) Vianney Brouard, ENS de Lyon, UMPA, CNRS UMR 5669, 46 All´ee d’Italie, 69364 Lyon Cedex 07, France; E-mail: vianney.brouard@ens-lyon.f. Table of Links Abstract & Introduction and presentation of the model Main results and biological interpretation First-order asymptotics of the mutant sub-populations for an infinite mono-directional grap First-order asymptotics of the mutant sub-populations for a general finite trait space (Theorem 2.1) Convergence for the stochastic exponents (Theorem 2.2) Acknowledgements & References Abstract We aim at understanding the evolution of the genetic composition of cancer cell populations. To this aim, we consider a branching individual based model representing a cell population where cells divide, die and mutate along the edges of a finite directed graph (V, E). The process starts with only one cell of trait 0. Following typical parameter values in cancer cell populations we study the model under large population and power law mutation rates limit, in the sense that the mutation probabilities are parameterized by negative powers of n and the typical sizes of the population of our interest are positive powers of n. Under non-increasing growth rate condition (namely the growth rate of any sub-population is smaller than the growth rate of trait 0), we describe the time evolution of the first-order asymptotics of the size of each sub-population on the log(n) time scale, as well as in the random time scale at which the initial population, resp. the total population, reaches the size n t . In particular, such results allow to characterize whose mutational paths along the edges of the graph are actually contributing to the size order of the sub-populations. Without any condition on the growth rate, we describe the time evolution of the orders of magnitude of each sub-population. Adapting techniques from [13], we show that these converges to positive deterministic non-decreasing piecewise linear continuous functions, whose slopes are given by an algorithm. Keywords: cancer evolution, multitype branching processes, finite graph, long time behavior, power law mutation rates, population genetics. 1 Introduction and presentation of the model In the present work the population of cells will be studied in different time-scales: the random timescale and the following deterministic approximation where For any finite oriented labeled graph (V, E, L) under the following non-increasing growth rate condition Without any assumption on the growth rate function λ, the study is made on the deterministic timescale of Equation (4). As in [13, 3, 5, 8, 14, 2, 30] the asymptotic behaviors are obtained on the following stochastic exponent processes The results are presented in Theorem 2.2. It is the exponent as a power of n that is tracked for any sub-populations, whereas Theorem 2.1 gives directly the size order on n, this is a refined result. Up to our knowledge, it is the first model considering the power law mutation rates regime (1) capturing this level of refinement on the asymptotic behaviors. Two new significant results emerge. First it shows the remarkable result that under Assumption (5) the randomness on the first-order asymptotics of any mutant sub-populations is fully given by the stochasticity of only one random variable W -encoding the randomness on the long time for the lineage of wild-type cells issued from the initial cell. It means that the stochasticity for any mutant sub-population is fully driven, at least at the first-order asymptotics, by the randomness on the growth of the wild-type population and not from the dynamics of any lineage of a mutant cell, as well as the stochastic processes generating mutations. Second it characterizes exactly whether a mutational path on the graph structure of the trait space asymptotically contributes to the growth of the mutant sub-populations. Whereas having asymptotic results on the stochastic exponents only allows to discriminate some paths and not to determine exactly whose paths are actually contributing to the asymptotic growth of the mutant sub-populations. More precisely, if the weight of a path is defined as the sum of the label of its edges, asymptotic results on the stochastic exponent gives that for every trait v, among the paths from 0 to v only those with the less weight might contribute to the asymptotic growth of trait v. On the contrary, having results directly on the first-order asymptotics of the mutant sub-populations allows to discriminate among those paths with the less weight those which actually contributes to the dynamics of trait v. In particular among those paths with the less weight only those with the maximal number of neutral mutations on their edges have an asymptotic impact on the growth of trait v. Indeed an additional multiplicative factor of order log(n) for each neutral mutation of a path is captured when looking at the first-order asymptotics and is obviously not captured with asymptotic results only on the stochastic exponents. Moreover it is the first time that this power-law mutation rates regime is studied in the random timescale of Equation (3) up to our knowledge. From the biological point of view it is more interesting to get result on such random time-scale instead of the deterministic one. We obtain that the randomness on the first-order asymptotics of any mutant sub-populations is fully given by the stochasticity on the survival of the lineage of wild-type cells issued from the initial cell. As in [7, 6], compared to the different models in [13, 3, 5, 8, 14, 2, 16], the initial population Z (n) (0) is not assumed to have a macroscopic size. It introduces a supplementary randomness on how the wild-type population is stochastically growing to get a macroscopic size. But contrary to [7, 6], we do not condition on the survival of the wild-type population or on the stopping times of Equation (3) to be finite. In [28] Nicholson and Antal study a similar model under a slightly less general non-increasing growth rate condition. More precisely, in their case all the growth rates of the mutant populations are strictly smaller than the growth rate of the wild-type population: ∀v ∈ V \{0}, λ(v) < λ(0). But the main difference remains the mutation regime. In their case, only the last mutation is in the power law mutation rates regime, all other mutations have a fixed probability independent of n. In Theorem 2.1 the case where all mutations are in the power law mutation rates regime is treated. Also Nicholson and Antal are interested in obtaining the distribution of the first time that a mutant sub-population gets a mutant cell. Whereas in the present work the first-order asymptotics of the sizes of the mutant sub-populations over time are studied. In [29] Nicholson, Cheek and Antal study the case of a mono-directional graph where the time tends first to infinity with fixed mutation probabilities. In particular they obtain the almost sure first-order asymptotics of the size of the different mutant sub-populations. Under the non-increasing growth rate condition, they are able to characterized the distribution of the limit random variables they obtained. Without any condition on the growth rates, they study the distribution of the random limit they obtained under the small mutation probabilities limit, using the hypothesis of an approximating model with less stochasticity. Notice that the mutation regime they study is not the large population power law mutation rates regime of Eq. (1) as considered in the present work. Under the latter regime both the size of the population goes to infinity and the mutation probabilities to 0, through the parameter n, see Equation (1). In [18] Gunnarson, Leder and Zhang study a similar model as the one in the present work and are also interested in capturing the evolution over time of the genetic diversity of a population of cells, using in their case the well-known summary statistic called the site frequency spectrum (SFS). The main difference is the mutation regime because they are not considering the power law mutation rates limit. In their case the mutation probabilities are fixed. Also, they restrict the study to the neutral cancer evolution case. In particular, as in the present work, they capture the first-order asymptotics of the SFS at a fixed time and at the random time at which the population first reaches a certain size. Two noticeable similarities in the results are that the first-order asymptotics of the SFS converges to a random limit when evaluated at a fixed time and to a deterministic limit when evaluated at the stochastic previous time. One could argue that in the present work the correct convergence for the latter case is actually a stochastic limit. But the stochasticity is fully given by the survival of the initial lineage of cells of trait 0, so conditioned on such an event at the end the limit is a deterministic one. In particular the results of Gunnarson, Leder and Zhang are all conditioned on nonextinction of the population. In [16] Gamblin and Lambert study a model of an exponentially growing asexual population that undergoes cyclic bottlenecks under the large population power law mutation rates regime. Their trait space is composed of 4 sub-populations 00, 10, 01 and 11, where two paths of mutations are possible 00 7→ 10 7→ 11 and 00 7→ 01 7→ 11. They study the special case where one mutation (10) has a high-rate but is a weakly beneficial mutation whereas the other mutation (01) has a low-rate but is a strongly beneficial mutation. In particular they show the noticeable result that due to cyclic bottlenecks only a unique evolutionary path unfolds but modifying their intensity and period implies that all paths can be explored. Their work relies on a deterministic approximation of the wild-type sub-population 00 and some parts of the analysis of the behavior of the model is only obtained due to heuristics. The present work, and more specifically Theorem 2.2 because they are considering selective mutations, can be used and adapted to consider the case of cyclic bottlenecks in order to prove rigorously their results, in the specific trait space that they consider as well as on a general finite trait space. The rest of the paper is organised as follows. In Section 2 the results and their biological interpretations are given. Sections 3 and 4 are dedicated to prove Theorem 2.1, which assumes Equation (5). In Section 3 the mathematical definition of the model is given for an infinite mono-directional graph as well as the proof in this particular case. The generalisation of the proof from an infinite mono-directional graph to a general finite graph is given in Section 4. In Section 5, Theorem 2.2 is proved adapting results from [13].

Genetic Composition of Supercritical Branching:Abstract & Introduction and Presentation of the Model

Authors: (1) Eugene Y. S. Chua, Division of the Humanities and Social Sciences, California Institute of Technology; (2) Eddy Keming Chen, ‡Department of Philosophy, University of California. Table of Links Abstract & Introduction Decoherence and Branching The Born Rule Discussion Conclusion and References 5 Conclusion We suggest that the Evereian understanding of decoherence and branching, as well as the justifications for the Born rule, apply to both WFRE and DMRE. Hence, the theoretical benefits of DMR are available on EQM. Another consequence is that Everettians face a choice between two types of theories, one allowing only pure states for the multiverse and the other allowing mixed states also. The choice will not be based on different understandings of the branching structure or the Born rule, as the Everettian justifications equally apply in both theories, but must involve some other theoretical considerations. In any case, the availability of different versions of EQM is an interesting example of empirical underdetermination. Its implications and possible resolutions are questions we leave for future work. Acknowledgements For helpful feedback, we thank Jefferey Barrett, Charles Sebens, Kelvin McQueen, Katie Robertson, Simon Saunders, Tony Short, Karim Thebault, David Wallace, and the ´ participants at the 2023 Workshop on Relational Clocks, Decoherence, and the Arrow of Time at the University of Bristol, and the 2022 California Quantum Interpretation Network Conference at Chapman University. References Albert, David. “Elementaryantum Metaphysics”. In: Bohmian Mechanics and Quantum theory: An Appraisal. Ed. by J. T. Cushing, Arthur Fine, and Sheldon Goldstein. Kluwer Academic Publishers, 1996, pp. 277–284. — Time and chance. Cambridge: Harvard University Press, 2000. Allori, Valia et al. “Predictions and primitive ontology in quantum foundations: a study of examples”. In: The British Journal for the Philosophy of Science 65.2 (2013), pp. 323–352. Baker, David. “Measurement outcomes and probability in Everettian quantum mechanics”. In: Studies in History and Philosophy of Science Part B: Studies in History and Philosophy of Modern Physics 38.1 (2007), pp. 153–169. Barrett, Jeffrey. “Everettian Quantum Mechanics”. In: The Stanford Encyclopedia of Philosophy. Ed. by Edward N. Zalta and Uri Nodelman. Summer 2023. Metaphysics Research Lab, Stanford University, 2023. Chen, Eddy Keming. “From time asymmetry to quantum entanglement: The Humean unification”. In: Nousˆ 56 (2022), pp. 227–255. — “Fundamental Nomic Vagueness”. In: The Philosophical Review 131(1) (2022). — “Quantum Mechanics in a Time-Asymmetric Universe: On the Nature of the Initial Quantum State”. In: The British Journal for the Philosophy of Science 72.4 (2021), pp. 1155–1183. — “Realism about the wave function”. In: Philosophy Compass 14.7 (2019). — “Strong Determinism”. In: Philosophers’ Imprint forthcoming (2022). — “Time’s Arrow in a Quantum Universe: On the Status of Statistical Mechanical Probabilities”. In: Statistical Mechanics and Scientific Explanation: Determinism, Indeterminism and Laws of Nature. Ed. by Valid Allori. Singapore: World Scientific, 2020. Deutsch, David. “Quantum Theory of probability and decisions”. In: Proceedings of the Royal Society of London. Series A: Mathematical, Physical and Engineering Sciences 455.1988 (1999), pp. 3129–3137. Durr, Detlef et al. “On the role of density matrices in Bohmian m ¨ echanics”. In: Foundations of Physics 35.3 (2005), pp. 449–467. Kent, Adrian. “307One World Versus Many: e Inadequacy of Everettian Accounts of Evolution, Probability, and Scientific Confirmation”. In: Many Worlds?: Everett, Quantum Theory, and Reality. Oxford University Press, June 2010. Maroney, Owen. “The Density Matrix in the de Broglie–Bohm Approach”. In: Foundations of Physics 35.3 (2005), pp. 493–510. McQueen, Kelvin J. and Lev Vaidman. “In defence of the self-location uncertainty account of probability in the many-worlds interpretation”. In: Studies in History and Philosophy of Science Part B: Studies in History and Philosophy of Modern Physics 66 (2018), pp. 14–23. Ney, Alyssa. The world in the wave function: a metaphysics for quantum physics. Oxford University Press, 2021. Nielsen, Michael A and Isaac L Chuang. Quantum computation and quantum information. Cambridge university press, 2010. Robertson, Katie. “In search of the holy grail: How to reduce the second law of thermodynamics”. In: The British Journal for the Philosophy of Science 73.4 (2022), pp. 987– 1020. Saunders, Simon. “Branch-counting in the Everett interpretation of quantum mechanics”. In: Proceedings of the Royal Society A 477.2255 (2021), p. 20210600. Schlosshauer, Maximilian A.Decoherence: and the quantum-to-classical transition. Springer Science & Business Media, 2007. Sebens, Charles T. and Sean M. Carroll. “Self-Locating Uncertainty and the Origin of Probability in Everettian Quantum Mechanics”. In: British Journal for the Philosophy of Science 1 (2018), axw004. Tappenden, Paul. “Evidence and Uncertainty in Everett?s Multiverse”. In: British Journal for the Philosophy of Science 62.1 (2011), pp. 99–123. Vaidman, Lev. “Derivations of the Born Rule”. In: antum, Probability, Logic: The Work and Influence of Itamar Pitowsky. Ed. by Meir Hemmo and Orly Shenker. Cham: Springer International Publishing, 2020, pp. 567–584. — “Many-Worlds Interpretation of Quantum Mechanics”. In: The Stanford Encyclopedia of Philosophy. Ed. by Edward N. Zalta. Fall 2021. Metaphysics Research Lab, Stanford University, 2021. — “On schizophrenic experiences of the neutron or why we should believe in the many-worlds interpretation of quantum theory”. In: International Studies in the Philosophy of Science 12.3 (1998), pp. 245–261. Wallace, David. e Emergent Multiverse: Quantum Theory According to the Everett Interpretation. Oxford University Press, 2012. — “The sky is blue, and other reasons quantum mechanics is not underdetermined by evidence”. In: arXiv preprint: 2205.00568 (2022). This paper is under CC 4.0 license. available on arxiv

BRANCH

branchfurniture.com

-- employees

Since n.d.

COMPANY RANKING

BRANCH

EVERGREEN INDEX #4139

Representing this company? Click here to claim and customize this page!

Branch WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

BRANCH

branchfurniture.com

-- employees

Since n.d.

COMPANY RANKING

BRANCH

EVERGREEN INDEX #4139

RELATED COMPANIESRANK

STORIES ABOUT BRANCH

Representing this company? Click here to claim and customize this page!

Branch WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!