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

Branch

branch

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

Decoherence, Branching, and the Born Rule in a Mixed-State Everettian Multiverse: Conclusion

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 2 Decoherence and Branching 2.1 Decoherence for Wave Function Realism In other words, any measurement on the system S, entangled with E, effectively ignores the quantum interference between the macroscopically superposed component states. Notice that the interference terms show up only at the subsystem level (3) and not explicitly at the universal level (2). In §2.2 we shall see that although the story of decoherence applies the same way in DMR, “interference terms” also show up at the universal level, even though, as it is still the case, they make almost no contribution to the evolution of the component states. 2.2 Decoherence for Density Matrix Realism – Pure States 2.3 Decoherence for Density Matrix Realism – Mixed States In this case, we can say that there are not four branches for the universal density matrix (23), but three: Compared to the two multiverses (17 and 18) considered in the previous section, this multiverse is more expansive. It contains all the branches of the previous two. Decoherence is approximate, and so is branching of the Everettian multiverse. They both somewhat depend on how we define macrostates and what counts as macroscopically indistinguishable. For example, with a more fine-grained partition of macrostates, we may as well count the multiverse (23) as having four branches instead of three. While this example is a toy model, we believe it’s representative of how branching occurs in a mixed-state multiverse, and is in line with the general Everettian stance on branching and decoherence. This paper is under CC 4.0 license. available on arxiv

Decoherence and Branching in a Mixed-State Everettian Multiverse

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 Abstract In Everettian quantum mechanics, justifications for the Born rule appeal to selflocating uncertainty or decision theory. Such justifications have focused exclusively on a pure-state Evereian multiverse, represented by a wave function. Recent works in quantum foundations suggest that it is viable to consider a mixedstate Everettian multiverse, represented by a (mixed-state) density matrix. Here, we develop the conceptual foundations for decoherence and branching in a mixedstate multiverse, and extend the standard Everettian justifications for the Born rule to this setting. This extended framework provides a unification of ‘classical’ and ‘quantum’ probabilities, and additional theoretical benefits, for the Everettian picture. 1 Introduction Everettian quantum mechanics (EQM) is a minimalist interpretation of quantum mechanics with some counter-intuitive features (Barrett 2023; Vaidman 2021). Instead of attempting to collapse the quantum state or adding extra variables to obtain a definite outcome for each experiment, it proposes to take unitary quantum mechanics as fundamental and replace our single-world ontology with a multiverse, where every possible outcome of an experiment is realized in some branch (a parallel world). Hence it is also sometimes called the ‘many-worlds’ interpretation. There are two main issues with EQM, one metaphysical and the other epistemological. The metaphysical issue concerns the ontology of EQM. How do we obtain the appearance of a classical world, with definite records and observers, from the quantum state? A much discussed solution appeals to decoherence, with its ability to suppress interference and give rise to an “emergent multiverse” (Wallace 2012). The universal quantum state evolves into one with many branches, each representing an emergent (quasi-)classical world. The epistemological issue concerns the understanding of probability in EQM. A key postulate of quantum mechanics, and a crucial element of its empirical confirmation, is the Born rule: the probability of observing a certain outcome is given by the squared amplitude of the quantum state. How should we make sense of this probability when every measurement outcome occurs on some branch of the Everettian multiverse, and what justifies the interpretation of the squared amplitutdes as probabilities? There are several responses to the probability issue. The Deutsch-Wallace program understands probability in terms of the betting preferences of agents within the multiverse, which uses a decision-theoretic representation theorem to prove that the agent’s credences must satisfy the Born rule, on pain of irrationality (e.g. Deutsch 1999, Wallace 2012). The Sebens-Carroll (2018) and McQueen-Vaidman (2018) programs understand probability in terms of self-locating uncertainty of a localized agent on some branch, employing certain epistemic principles – such as “separability” or “symmetry” – to prove that the agent’s self-locating uncertainty must satisfy the Born rule. Promising as they may be, these defenses and justifications of EQM have an apparent limitation. They focus exclusively on the case of a universal pure state, where the quantum state of the multiverse is represented by a wave function. Defenders of EQM, like many other realist interpreters, regard the universal pure state as representing something objective and mind-independent. However, recent works in quantum foundations (Allori et al. 2013; Chen 2021; Durr et al. 2005; Maroney 2005; Robertson ¨ 2022; Wallace 2012) suggest that the above approach to realism, based on the wave function, is not the only possibility for realism about the quantum state. It’s also viable – and in some circumstances even more theoretically attractive – to take a realist stance based on the density matrix (Chen 2021). On this view, we can associate (possibly mixed-state) density matrices, rather than (necessarily pure-state) wave functions, to isolated systems and even to the entire universe. While density matrices are conventionally used to represent ignorance about some underlying wave function or the external environment, it’s also possible to regard density matrices as fundamental. On the new picture, the universe as a whole can be aptly represented by a fundamental density matrix evolving unitarily according to the von Neumann equation. In contrast, on the standard picture, it is represented as a wave function evolving unitarily according to the Schrodinger equation. If the fundamental density matrix in this new realist picture is mathematically the same as that of the “ignorance” density matrix in the standard picture, the two theories will be empirically equivalent, since they make the same statistical predictions for all experiments. All wave functions correspond to some pure-state density matrices, but not all density matrices have corresponding wave functions. us, realism based on the density matrix allows for more quantum states than realism based on the wave function. The former is also compatible with a theoretically attractive package – the Wentaculus – which provides a unified explanation for quantum phenomena and the thermodynamic arrow of time (Chen 2020, Chen 2021, Chen 2022a, Chen 2022b). Following Chen (2021, 2019), we call this new picture Density Matrix Realism (DMR) and the old one Wave Function Realism (WFR). We denote the Everettian versions of DMR and WFR as DMRE and WFRE respectively. (Note that this is a wider conception of quantum state realism than that of Albert (1996) and Ney (2021).) This project has several conceptual payoffs. First, it requires us to clarify the ontological structure of the multiverse and the requirements of decoherence. As it turns out, branching requires decoherence but decoherence does not require a universal pure state. The story of decoherence applies both to pure and mixed states, which has been underappreciated in the literature. Second, with the access to a larger state space, Everettians can explore new theoretical possibilities that are naturally suggested by DMR. For example, DMRE provides the basis for a unified account of probability that may be absent on WFRE. On WFRE, without knowing what the universal wave function is, we may assign a density matrix ρ to represent our epistemic state. The probabilities we extract from ρ range over various possible candidate multiverses. As such, it is not interpreted as self-locating uncertainty or betting preferences of agents within a multiverse, and must be treated as a distinct source of probability (e.g. statistical mechanical / classical probability of possible initial conditions). In contrast, DMRE allows us to regard ρ as representing the actual fundamental quantum state of the multiverse. We have the option to posit just one source of probability, corresponding to the weights associated with branches of the actual mixed-state multiverse This paper is under CC 4.0 license. available on arxiv

Decoherence, Branching, and the Born Rule in a Mixed-State Everettian Multiverse

মিশ্র-রাষ্ট্র এভারেটিয়ান মাল্টিভার্সে ডিকোহেরেন্স, ব্রাঞ্চিং এবং জন্মগত নিয়ম

Dekohärenz, Verzweigung und die geborene Regel in einem Everettian-Multiversum mit gemischten Zuständen

Decoherencia, ramificación y regla nacida en un multiverso Everettiano de estados mixtos

Décohérence, ramification et règle de naissance dans un multivers everettien à états mixtes

मिक्स्ड-स्टेट एवरेटियन मल्टीवर्स में डिकोहेरेंस, ब्रांचिंग और बोर्न रूल

混合状態のエベレッティアン多元宇宙におけるデコヒーレンス、分岐、およびボーンルール

혼합 상태 에버레시안 다중우주의 결맞음, 분기 및 타고난 규칙

Decoerência, ramificação e a regra nascida em um multiverso everettiano de estado misto

Декогеренция, ветвление и правило Борна в эвереттовской мультивселенной со смешанными состояниями

Karma Durumlu Everettian Çoklu Evreninde Eşevresizlik, Dallanma ve Doğuş Kuralı

Sự trang trí, phân nhánh và quy tắc bẩm sinh trong đa vũ trụ Everettian trạng thái hỗn hợp

混合态埃弗里特多重宇宙中的退相干、分支和诞生规则

*We will survive, believe me!* Something that all junior developers share, regardless of the stack they are working on, whether it's backend, frontend, mobile, JavaScript, C#, Angular, PHP, or whatever the focus of their work is: managing branches, making commits, and creating Pull Requests. One of the key factors to transform your career is to refine your communication with your team more and more. The clearer you are in presenting your ideas, doubts, and opinions, the more value you will have. So, as the idea of this text is to be practical, let's go to our main topics: ; ; and . Managing Branches Commits Pull Requests Managing Branches is a model for managing branches. The idea is to create, from the main branch, specific branches for the development of your project, complete the development of what you are creating, and merge it back into the main branch. Gitflow In Practice: Your task for the week will be to include a social login with Facebook in your project. What's the first step? Start your project from the main branch (main), switch to the branch where the project is being developed (develop), and from there, create a new branch for this task and work on it (feat/social-login-facebook). Only then do you start your work. When you finish your work, this branch will be merged into the “develop” branch. What are the most common types of branches? : It is the main branch, reflecting the most "stable" version of the product you are working on. Main : Developers use this branch to start their projects, and it serves as the base code. Develop : This branch is created from the development branch for specific tasks. It is considered a temporary branch that, upon completing its task, should be merged back into Develop. Feature : Similar to the Feature branch in that it's temporary, but it is used for immediate fixes. It can be created from the developed or main branches. Hotfix : This branch is considered a "pre-main." When various tasks are completed and a significant stage of development is finished, a release branch is created from the development branch. It serves more as a milestone for the type of update the main branch will receive. Release Ok, now that you have a better understanding of how branches work, how can you apply this in your daily routine? Free extensions are available in the Visual Studio library, such as , which makes all these branch changes visible and distinct. Let's see: Git Graph Through Git Graph, you have access to the graph itself, showing the progression of branches, the branch description, the creation date, the author, and the commit ID. Git Graph is not only designed for a graphical view of the branching order but also for understanding the commits, where they are made, and how they come together. There is also a specific way to name your branches to adhere to this flow, typically using a prefix like feature/, hotfix/, or release/. You can read more about the topic . here In addition to Gitflow, there are other branch management strategies, such as GitHub Flow, GitLab Flow, OneFlow, and Trunk-Based Development. If you want to delve deeper into the subject, you can read it . here Commits Commit is the tool that allows you to explain the intent behind the changes you made in the code. They should be concise and descriptive, with a clear and specific purpose. Commits act like checkpoints. In addition to explaining the purpose of your changes, they also serve as a way to roll back in case your code is not approved, allowing you to revert to the previous commit. But just like GitFlow, there are also commit standards. The one I've been using is . Conventional Commits Using Conventional Commits makes its purpose very clear since every commit starts with either chore, feat, fix, refactor, docs, perf, style, test, build, ci, or env: : Updating tasks that do not cause changes in the production code but involve tool changes, configuration changes, and libraries. chore : New features or any other new implementations to the code. feat : Bug fixes. fix : Used for any changes that are made in the code but do not alter the final functionality of the impacted task. refactor : Inclusion or modification of documentation files. docs : Changes to improve performance. perf : Formatting changes in the code presentation that do not affect the code's meaning. style : Adding missing tests or fixing existing tests. test : Changes that affect the build system or external dependencies. build : Changes in CI configuration files and scripts. ci : Modifications or additions to configuration files in continuous integration (CI) processes and methods. env Since the commit is a way to create a checkpoint, it should contain a fragment of your task. In our case, you could divide the task of adding login through Facebook into the following commits: Creating a relationship with Facebook to receive a token feat: Add integration with Facebook to receive the token Creating necessary permissions on Facebook feat: Configure permissions on Facebook for integration Creating a component to perform the request feat: Implement component for the request to Facebook Creating verification of the Facebook token with the user in the project feat: Add verification of Facebook token with the user in the project Testing integration with Facebook test: Perform integration tests with Facebook Creating documentation for the integration with Facebook docs: Add documentation for integration with Facebook By making commits in this way, when you create your PR, it will make your life easier, as it becomes clearer what should be included in the PR since you have already described everything you did in the code through the commits. Now, what tools can help you maintain standardized commits? and . Commitlint Husky With Commitlint, you can create a commit verification filter that needs to follow a specific format (conventional commits) to be effective. And how do you apply to ? By using and Husky, which compare the established rules and what you wrote. If the pattern is not followed, it prevents the creation of the commit, asking you to correct it. It is essentially an automation of the commit verification process, limiting their size and allowing them to be divided into a short message, scope, and commit description (if necessary). Commitlint Commitizen For the application of these tools, I recommend these two texts: 1 - Why Should you use Commitizen + Husky for conventional commit and have organised lint 2 - Como adicionar hooks de commit ao Git com Husky para automatizar tarefas Pull Request (PR) And now what? You created your branch, completed the defined task, created checkpoints with commits, and now you need to make the PR to add your branch to the developed branch. How to do it? A Pull Request is the way you ask to merge your branch into the develop branch. It is the method we use to present your work to be reviewed by other developers and approved. The main purpose of the PR is to present what has been done, validate the work, or point out changes that need to be made and include your code in the development branch. As a communication tool, although it does not have a convention like the previous ones, there are some ideas to keep in mind when making your PR. Your PR should be based on WHY, WHAT, and HOW. : Why your PR is necessary, and what problem caused your need. WHY : Describe what your PR does, not in a technical way, but what the practical effect of your code change is. WHAT : This is the space you should use to make it clear, in a technical way, what changes you made. You should use your commits as a guide for what will be explained, which files were altered/created/deleted, how it happened, and why it happened this way. That would be the basic necessity. HOW Now, two points to pay attention to: PRs should contain between 200 and 400 lines of code change; more than that, there's a possibility that an error may go unnoticed. : The number of code changes Your PR is the moment to explain what you did, but it doesn’t mean writing a book. Just like with commits, you have to focus on being concise and clear. Conciseness: Finally, there is other information you can add to facilitate the interpretation of your PR, such as the type of changes made, screenshots or videos of the effects of your change on the project, adding the link to the Task you resolved, some form of checklist, and a section for additional information you may want to add. You can find a screenshot and the to the example PR template I usually use. link I also recommend Kara's on the subject, which is much more comprehensive than this. article : Some teams may have their template; if yours doesn't, you can check if it's possible to add one. itself provides a detailed description of how to do this. PS GitHub Conclusion Knowing how to use and create branches, commits, and pull requests are basic concepts, but not everyone gives them the importance they deserve. Although this is not directly related to code, understanding how to use branches, commits, and pull requests is fundamental and highly valuable because it's the way developers can communicate, explain their work, and receive feedback for improvement. This is the first text in a series of guides that I intend to create. As I continue learning in my day-to-day, I'll keep publishing these ideas.

Your Junior Dev Survival Guide to Managing Branches, Commits and PR

In the last decade leading , I’ve worked with a lot of talented software developers, and early on in their tenure, I usually end up saying the same thing: ship smaller units of software and limit the size of your local host branches. Why? Here are the two key reasons and one big ole but: HackerNoon 1. Users reap more benefits from - and give feedback to - your work while you continue to work towards completing the project. If you have a project that’s 6 months worth of work, and doesn’t go live for 6 months, that’s 5 months and 30ish days of the users reaping zero benefits from your work. Only when it’s live can the rest of the internet even have a chance to benefit from what you ship. And even then, that’s just when the massive uphill battle for adoption starts. If you were to instead ship part of the project every week, users would start to gain value over the lifecycle of the project. , my former colleague, once put it to me as “we should continue adding atomic units of value and do as many releases as it takes. We could easily have 10 releases on [functionality] before we're happy with it and ready to move on.” Dane Lyons As the CEO, I often judge new hires on how long it takes them to become profitable contributors. In sales, this is more cut and dry, did their sales exceed their compensation? There’s of course other things to consider, like marginal costs on marketing, infrastructure, etc., but however you slice it, it’s more difficult to measure how a software developer impacts the bottom line than a salesperson. If you are ramping up in a new role as a software developer, I recommend successfully trying to string together singles before going for home runs. In the game of software development, there are no universal rules for what the score is. Sure some people assign point systems and others define KPIs, but at the end of the day, it’s the people using your product who determine if and how you are creating value or not. By shipping sooner, you receive feedback sooner. The people using your software will make it more clear how to build and not build the project’s next atomic unit. 2. The further your branch deviates from production reality, the harder it is for teammates to contribute to your project and move adjacent projects forward. The externalities from not shipping the most up to date version can be harder to see at first. Everything is connected. In a product like HackerNoon for example, the profile page and story page do not exist in vacuums; they exist as connected pages within one product. If changes happen to how one page functions, it affects how all pages connected to it function. If your local branch is very large, other changes that happen on pages or functions connected to it, will often not work once your obese branch finally ships to production. This breaks things. This creates bugs. This forces the need to redo work. This creates a desire from your teammates to want to not work with you. This could even create a product experience that is worse than the one you already had, before all the work you put into your local branch. By making smaller changes more regularly you are empowering others to contribute. They feel what they ship will also work because you both already agreement what the production baseline is. Incremental is your bff. It connects you to reality. If the incremental changes are negatively affecting the product, what makes you think larger changes in the same direction will positively affect the product experience? And the big old but is: don’t be afraid of bold projects that may become branches that are too large because you are a bad mofo that is capable of making a difference to how this fucking thing works for people. Some projects simply have to be large branches. For example, things with massive dependencies like new databases can just be so ingrained in existing usage that it’s best to turn back the clock and approach the project like a yearly on premise 2.0 release. And other breakthrough technologies, like ChatGPT, took so long to build that it just wouldn’t make sense for adoption to release an untrained, incomplete, shit UX version of the new technology. Take big swings. When you have the runway. When you have the team onboard. But don’t grandiose yourself. Most of the time software development isn’t reinventing the wheel. It’s simply shipping the next atomic unit.

Ship Smaller Units of Software and Limit the Sizes of Your Local Host Branches

সফ্টওয়্যারের ছোট ইউনিট প্রেরণ করুন এবং আপনার স্থানীয় হোস্ট শাখাগুলির আকার সীমিত করুন

Versenden Sie kleinere Softwareeinheiten und begrenzen Sie die Größe Ihrer lokalen Host-Zweigstellen

Envíe unidades de software más pequeñas y limite el tamaño de sus sucursales locales de alojamiento

Expédiez des unités logicielles plus petites et limitez la taille de vos branches hôtes locales

सॉफ़्टवेयर की छोटी इकाइयाँ भेजें और अपनी स्थानीय होस्ट शाखाओं का आकार सीमित करें

より小さい単位のソフトウェアを出荷し、ローカル ホスト ブランチのサイズを制限する

더 작은 단위의 소프트웨어를 배송하고 로컬 호스트 지점의 크기를 제한하십시오.

Envie unidades menores de software e limite o tamanho de suas filiais de host local

Поставляйте меньшие единицы программного обеспечения и ограничивайте размеры локальных ветвей хоста

Daha Küçük Yazılım Birimleri Gönderin ve Yerel Ana Bilgisayar Şubelerinizin Boyutlarını Sınırlandırın

Gửi các đơn vị phần mềm nhỏ hơn và giới hạn kích thước của các nhánh máy chủ cục bộ của bạn

交付较小的软件单元并限制本地主机分支的大小

In my last blog, We learned about version control and its use in software development. We also understood some of the basic commands like config, clone, commit, and push. As a beginner both in git and a project, these commands come in handy and get us going. git As we grow and our project grows, so does the team. With all the growth, it becomes tough for developers to manage code and keep track of all the contributions. This is where branching comes into the picture. What is a branch? In Git, a branch is a new/separate version of the main repository. It represents an independent line of development. It also serves as an abstraction for the edit/stage/commit process, meaning that whatever changes you make in a branch do not affect your master/main . [T&C Apply] Some Branching commands Create a new branch, But do not switch to it git branch <branchname> Switch to an already created branch git checkout  <branchname> Create a new branch and switch to the branch git checkout -b <branchname> List all the branches in your repo, and it also shows what branch you're currently in git branch Push the branch to your remote repository so that others can use it git push origin <branchname> Push all branches to your remote repository git push --all origin Delete a specific branch git branch -d <branchname> Delete a branch on your remote repository git push origin:<branchname> Well... That was a lot of branching knowledge, and contrary to the law of conservation of energy, a branch can be created or destroyed (deleted), and the only way to preserve it is to merge it to master or to its target finally. What is a merge? Merge is the process of taking the contents of a source branch and integrating them with a target branch. Remember the I had put earlier? It's time we trace back. T&C Let's get into a scenario where you were given a feature to implement i.e., Heart Glasses for your octopus ( ). What will you do? Here onwards, we will call him Octie You will create the heart_glass branch from your master branch using one of the above branching commands. Once you are done with all your changes and know that the glass will look good on Octie, You go ahead and merge your heart_glass branch to your master branch, and maybe then delete the heart_glass branch, and you will have all your changes in the master now. Octie is looking good there, and while you were creating glasses, someone put a hat on Octie. Ain't that nice? The below image practically sums up the whole process - Some merge git commands merge a different branch into your active branch git merge <branchname> Fetch and merge changes on the remote server to your working directory git pull View all the merge conflicts git diff Preview changes, before merging git diff <sourcebranch> <targetbranch> In this blog post, we have deep-dived into branching and merging, and we are one step closer to becoming git masters. In the next blog post, we will try to cover resetting a branch, tagging, and so much more. I also intend to cover some less-known git features in this series. Do you know you can clone only a subdirectory from a git repo? More on this later! Stay tuned, follow me on social media channels, and subscribe to my newsletter to get updates on my upcoming posts. Feel free to comment on how you like my blog on the system design series or shoot me an email at connect@nandan.dev. If you have any queries, I will try to answer them. You can also visit my website to read some of the articles at https://nandan.dev/ Stay tuned & connect with me on my social media channels. Subscribe to my newsletter to get regular updates on my upcoming posts. Also published . here

Git Mastery: Branching, Merging, and Beyond

This blog assumes you know the ; otherwise, it might not make much sense. data lake table formats Branching and tagging are an important of Apache Iceberg, released in February 2023 as part of version 1.2.0. They unlock a new world of use cases and are an exciting evolution to the Iceberg snapshot. Iceberg co-creator Ryan Blue posted a blog Tags and Branches to introduce the features in March 2023. feature titled In this post, I will provide an overview of Iceberg snapshots, branches, and tags. Lastly, I will emulate these behaviors in Apache Hudi and Delta Lake. In a previous life as IT Director at a payroll and tax company, we often had situations where we needed to save a state of the data (like year-end) or backtest code for new regulations or features against existing data. We’d save that data to DAT tape for offsite storage. For scenario testing, I’d written some scripts that would extract data for an arbitrary list of clients and load it in the dev copy of the database. I used this same tool and method at several jobs for years. It wasn’t perfect, but it worked well, given the technology available at the time. How would I have done it differently on a modern data lake, specifically using Apache Iceberg? Let’s explore that.  But first, a little conceptual background. This blog assumes a basic understanding of Apache Iceberg. Understanding Apache Iceberg snapshots Apache Iceberg will create a of a table at a specific point in time when a table operation like AppendFile or RewriteFiles is used. This will generate a union of all associated manifests and their data files. Snapshots enable simple time-travel queries that allow you to read the state of a table at a particular point in time and see how it might change over time. snapshot Snapshots can be explicitly removed with the ExpireSnapshots . There are several methods provided that allow you to specify various parameters, such as expireOlderThan and expireSnapshotId. operation That should give you enough background for what follows, as tags and branches are more advanced snapshot lifecycle management methods. Using snapshot tags for time travel in Iceberg At its most basic, tags can be named snapshots that you choose to keep longer than your normal retention period and that you configure to expire automatically. Tags are an immutable label for a snapshot and really open up the possible use cases with snapshots. They are very similar to how commits in Git work. The RETAIN parameter allows you to automatically expire that snapshot instead of doing it manually. considered Using the example of my payroll/tax company, we wanted to preserve the state of our data at a year-end record and make it easily accessible for five years. In Iceberg, we could have done it like this: ALTER TABLE transactions CREATE TAG 2022_eoy RETAIN 1825 DAYS; I could then query that particular tag for whatever reason like this: SELECT * FROM transactions VERSION AS OF '2022_eoy'; It’s that simple! Some other ideas would be to tag a set of data you want to use to exercise a test suite whenever code gets changed or maybe to backtest a machine learning application.  Having a named snapshot makes it very convenient to find and use data from a particular point in time. How branches enhance tags in Iceberg Branches are a to a particular snapshot; it can be the current snapshot or a specific version specified during the creation. The difference between a tag and a branch can be confusing initially, but a tag is a named snapshot with its own expiration. A branch is a named copy of a snapshot that can also have its own expiration. That branch can be queried and written to, which would then create snapshots on the branch, which can also be tagged and branched. Branches allow you to work on different versions of a table in isolation. named reference These features enable a number of obvious use cases: A specific point in time retention for compliance purposes Isolate data for testing without impacting production workloads Robust data auditing (WAP) by allowing you to work with staged changes You can make branches of branches and even tag those branches if you like. Branches, like tags, also allow you to specify a retention value so they are automatically deleted after the retention period. Branches can be written multiple times, allowing you to exercise your tests multiple times before dropping or merging the data back. Having named references to data makes auditing via time-travel syntax significantly more apparent. How I could have used them Year-end processing, where we printed the tax forms for client customers, would take days to print, which was the only work that could happen while it was running because of the system design, so all the other processing would queue up. If we could have branched and tagged that year-end data, we could have done our new processing concurrently and also have that year-end snapshot that we could maintain and do any reports or reruns on as needed. For testing code changes, let’s say a new tax rate is coming out, and we need to do scenario runs with the new rates to show to the customers. I know this feature has to be completed in 30 days, so I will expire it after 45, just in case. In this case, I want to create the branch as of the current snapshot, so I don’t need to specify the one I want to branch. I could create the branch like this: ALTER TABLE transactions CREATE BRANCH new_tax_test RETAIN 45 DAYS; I can then perform actions against that branch by referencing with the same time-travel syntax: SELECT * FROM transactions VERSION AS OF new_tax_test; I can then insert data into that branch, which would create a new snapshot: INSERT INTO transactions AT BRANCH new_tax_test VALUES (1, 'a'), (2, 'b'); I could replace the branch with a different snapshot version if I needed to grab a different version of the data without changing my code references to exercise it. Retention time can also be changed during the update process. When I’m all done, I can remove the branch, either by waiting for the retention to expire or explicitly, like this: ALTER TABLE transactions DROP BRANCH new_tax_test Does Apache Hudi or Delta Lake support tags and branches? Great question; let’s look at how we would do something similar in those systems. Apache Hudi Instead of the Iceberg style of a snapshot, Apache Hudi serializes all table actions into an event log called Timeline. Every transaction on a Hudi table will create a new entry. This log allows the ability to read through a by specifying the read option's begin and end time. This is similar to an Iceberg snapshot. point in time That said, Hudi has a SNAPSHOT statement that can be to create a specific snapshot, but it can only be executed from the Hudi command line interface. A view of the snapshot can be named, similar to an Iceberg branch. To read that snapshot, you must restore it via the Hudi CLI. During the restore, (according to their docs). used you must bring down all your writer processes There doesn’t appear to be a concept of automatic expiration of snapshots; the only option I’m aware of is again through the Hudi CLI and executing a savepoint delete to remove a savepoint. The closest option I could for branching was the , which will make a copy of the selected data into a target output path in Hudi, parquet, or JSON format. You would then need to connect to the new location to perform any queries. This option could also be used to satisfy my example of wanting to save a backup of data at a particular point in time. find HoodieSnapshotExporter Delta Lake Delta also incorporates transaction logs along with their data files, like Hudi. The retention time to 30 days for the log files (data files are never automatically deleted; they must be removed explicitly via a VACUUM action), but the retention time can be configured by setting the interval for the table property , which sets the number of days. defaults logRetentionDuration delta.logRetentionDuration = "interval <interval>" You can time travel through any data with the log and data files available. This is analogous to the notion of a snapshot in Iceberg. There is the ability to have a start-from date or a start-from version with Delta. At , the seems like it could be a named checkpoint, but it’s the actual file name. Those values are retrieved from the output of a DESCRIBE HISTORY table_spec command, which you’d need to either retrieve or know to be able to use. The two versions look like this: first glance version SELECT * FROM transactions TIMESTAMP AS OF '2023-07-01';
SELECT * FROM delta.'/tmp/delta/transactions' VERSION AS OF 1023; Time travel over months or years isn’t feasible with Delta, as computing Delta’s state won’t scale. In addition, time travel still requires the data and logs to exist; also, note that when you perform a , the data files are removed. VACUUM As for branching, you can get close to it using the Delta operation. This will create a copy of an existing Delta Lake table at a specific version. Two types of clones are available: a deep clone and a shallow clone. A deep clone copies an existing table's table data and metadata, while a shallow clone simply copies the table metadata. CLONE Summary I’ve just touched the surface of what is possible with these features. For example, you can utilize even more robust scenarios, like snapshots of branches that could be tagged. These can be used to make time travel even more straightforward, facilitate machine learning training, and aid in data retention and removal for regulatory compliance (HIPPA, GDPR, CCPA, etc.) We also saw that these capabilities appear to be more involved to implement in Hudi and Delta, but granted, I’m not an expert in those formats; this is what I gleaned from reviewing the docs and blogs. What ideas can you come up with to help solve your data challenges? Make sure to review the docs for each format on the topic for specifics.

Branches & Tags: Comparing Iceberg, Hudi, and Delta Lake Tables

A Treatise on Domestic Economy; For the Use of Young Ladies at Home and at School by Catharine Esther Beecher, is part of the HackerNoon Books Series. You can jump to any chapter in this book . ON DOMESTIC ECONOMY AS A BRANCH OF STUDY. here CHAPTER IV. ON DOMESTIC ECONOMY AS A BRANCH OF STUDY. The greatest impediment to making Domestic Economy a branch of study, is, the fact, that neither parents nor teachers realize the importance, or the practicability of constituting it a regular part of school education. It is with reference to this, that the first aim of the writer will be, to point out some of the reasons for introducing Domestic Economy as a branch of female education, to be studied at school. The first reason, is, that there is no period, in a young lady's life, when she will not find such knowledge useful to herself and to others. The state of domestic service, in this Country, is so precarious, that there is scarcely a family, in the free States, of whom it can be affirmed, that neither sickness, discontent, nor love of change, will deprive them of all their domestics, so that every female member of the family will be required to lend some aid, in providing food and the conveniences of living; and the better she is qualified to render it, the happier she will be, and the more she will contribute to the enjoyment of others. A second reason, is, that every young lady, at the close of her schooldays, and even before they are closed, is liable to be placed in a situation, in which she will need to do, herself, or to teach others to do, all the various processes and duties detailed in this work. That this may be more fully realized, the writer will detail some instances, which have come under her own observation. The eldest daughter of a family returned from school, on a visit, at sixteen years of age. Before her vacation had closed, her mother was laid in the grave; and such were her father's circumstances, that she was obliged to assume the cares and duties of her lost parent. The care of an infant, the management of young children, the superintendence of domestics, the charge of family expenses, the responsibility of entertaining company, and the many other cares of the family state, all at once came upon this young and inexperienced schoolgirl. Again; a young lady went to reside with a married sister, in a distant State. While on this visit, the elder sister died, and there was no one but this young lady to fill the vacant place, and assume all the cares of the nursery, parlor, and kitchen. Again; a pupil of the writer, at the end of her schooldays, married, and removed to the West. She was an entire novice in all domestic matters; an utter stranger in the place to which she removed. In a year, she became a mother, and ; while, for most of the time, she had no domestics, at all, or only Irish or Germans, who scarcely knew even the names, or the uses, of many cooking utensils. She was treated with politeness by her neighbors, and wished to return their civilities; but how could this young and delicate creature, who had spent all her life at school, or in visiting and amusement, take care of her infant, attend to her cooking, washing, ironing, and baking, the concerns of her parlor, chambers, kitchen, and cellar, and yet visit and receive company? If there is any thing that would make a kindly heart ache, with sorrow and sympathy, it would be to see so young, so amiable, so helpless a martyr to the mistaken system of female education now prevalent. "I have the kindest of husbands," said the young wife, after her narrative of sufferings, "and I never regretted my marriage; but, since this babe was born, I have never had a single waking hour of freedom from anxiety and care. O! how little young girls know what is before them, when they enter married life!" Let the mother or teacher, whose eye may rest on these lines, ask herself, if there is no cause for fear that the young objects of her care may be thrown into similar emergencies, where they may need a kind of preparation, which as yet has been withheld. her health failed Another reason for introducing such a subject, as a distinct branch of school education, is, that, as a general fact, young ladies be taught these things in any other way. In reply to the thousand-times-repeated remark, that girls must be taught their domestic duties by their mothers, at home, it may be inquired, in the first place, What proportion of mothers are qualified to teach a and system of Domestic Economy? When this is answered, it may be asked, What proportion of those who are qualified, have that sense of the importance of such instructions, and that energy and perseverance which would enable them actually to teach their daughters, in all the branches of Domestic Economy presented in this work? will not proper complete It may then be asked, How many mothers give their daughters instruction in the various branches of Domestic Economy? Is it not the case, that, owing to ill health, deficiency of domestics, and multiplied cares and perplexities, a large portion of the most intelligent mothers, and those, too, who most realize the importance of this instruction, actually cannot find the time, and have not the energy, necessary to properly perform the duty? They are taxed to the full amount of both their mental and physical energies, and cannot attempt any thing more. Almost every woman knows, that it is easier to do the work, herself, than it is to teach an awkward and careless novice; and the great majority of women, in this Country, are obliged to do almost every thing in the shortest and easiest way. This is one reason why the daughters of very energetic and accomplished housekeepers are often the most deficient in these respects; while the daughters of ignorant or inefficient mothers, driven to the exercise of their own energies, often become the most systematic and expert. actually do It may be objected, that such things cannot be taught by books. This position may fairly be questioned. Do not young ladies learn, from books, how to make hydrogen and oxygen? Do they not have pictures of furnaces, alembics, and the various utensils employed in the chemical agents? Do they not study the various processes of mechanics, and learn to understand and to do many as difficult operations, as any that belong to housekeeping? All these things are explained, studied, and recited in classes, when every one knows that little practical use can ever be made of this knowledge. Why, then, should not that science and art, which a woman is to practise during her whole life, be studied and recited? cooking It may be urged, that, even if it is studied, it will soon be forgotten. And so will much of every thing studied at school. But why should that knowledge, most needful for daily comfort, most liable to be in demand, be the only study omitted, because it may be forgotten? It may also be objected, that young ladies can get such books, and attend to them out of school. And so they can get books on Chemistry and Philosophy, and study them out of school; but they do it? And why ought we not to make sure of the most necessary knowledge, and let the less needful be omitted? If young ladies study such a work as this, in school, they will remember a great part of it; and, when they forget, in any emergency, they will know where to resort for instruction. But if such books are not put into schools, probably not one in twenty will see or hear of them, especially in those retired places where they are most needed. And is it at all probable, that a branch, which is so lightly esteemed as to be deemed unworthy a place in the list of female studies, will be sought for and learned by young girls, who so seldom look into works of solid instruction after they leave school? So deeply is the writer impressed with the importance of this, as a branch of female education, at school, that she would deem it far safer and wiser to omit any other, rather than this. will Another reason, for introducing such a branch of study into female schools, is, the influence it would exert, in leading young ladies more correctly to estimate the importance and dignity of domestic knowledge. It is now often the case, that young ladies rather pride themselves on their ignorance of such subjects; and seem to imagine that it is vulgar and ungenteel to know how to work. This is one of the relics of an aristocratic state of society, which is fast passing away. Here, the tendency of every thing is to the equalisation of labor, so that all classes are feeling, more and more, that indolence is disreputable. And there are many mothers, among the best educated and most wealthy classes, who are bringing up their daughters, not only to know how to do, but actually to do, all kinds of domestic work. The writer knows young ladies, who are daughters of men of wealth and standing, and who are among the most accomplished in their sphere, who have for months been sent to work with a mantuamaker, to acquire a practical knowledge of her occupation, and who have at home learned to perform all kinds of domestic labor. And let the young women of this Nation find, that Domestic Economy is placed, in schools, on equal or superior ground to Chemistry, Philosophy, and Mathematics, and they will blush to be found ignorant of its first principles, as much as they will to hesitate respecting the laws of gravity, or the composition of the atmosphere. But, as matters are now conducted, many young ladies know how to make oxygen and hydrogen, and to discuss questions of Philosophy or Political Economy, far better than they know how to make a bed and sweep a room properly; and they can "construct a diagram" in Geometry, with far more skill than they can make the simplest article of female dress. It may be urged, that the plan suggested by the writer, in the previous pages, would make such a book as this needless; for young ladies would learn all these things at home, before they go to school. But it must be remembered, that the plan suggested cannot fully be carried into effect, till such endowed institutions, as the one described, are universally furnished. This probably will not be done, till at least one generation of young women are educated. It is only on the supposition that a young lady can, at fourteen or fifteen years of age, enter such an institution, and continue there three years, that it would be easy to induce her to remain, during all the previous period, at home, in the practice of Domestic Economy, and the limited course of study pointed out. In the present imperfect, desultory, varying, mode of female education, where studies are begun, changed, partially learned, and forgotten, it requires nearly all the years of a woman's youth, to acquire the intellectual education now demanded. While this state of things continues, the only remedy is, to introduce Domestic Economy as a study at school. It is hoped that these considerations will have weight, not only with parents and teachers, but with young ladies themselves, and that all will unite their influence to introduce this, as a popular and universal branch of education, into every female school. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Catharine Esther Beecher (2007). A Treatise on Domestic Economy; For the Use of Young Ladies at Home and at School. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/21829/pg21829-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at , located at . www.gutenberg.org https://www.gutenberg.org/policy/license.html

ON DOMESTIC ECONOMY AS A BRANCH OF STUDY.

Branches of the Art of War

Have you heard that saying before? Think about it for a moment, and you realize just how true it is. "There's no growth in the comfort zone, and no comfort in the growth zone." Growth is a terribly uncomfortable experience; it's the process of pushing yourself beyond where you've been before. In the same way that we get growing pains as kids, we feel an internal pain every time our limits are exceeded – whether it be our social, physical, intellectual, or emotional limits. But whoever said an easy life was worth living? Oscar Wilde said, If we want to be people who really instead of just , we're going to have to get out of our comfort zones. "To live is the rarest thing in the world. Most people exist, that is all." live surviving (And we're going to have to do this on a regular basis!) If you feel a growing sense that your life has become stagnant – that you aren't doing your best or reaching your potential – I'm here to unpack the psychology behind those feelings and, most importantly, find out how you can escape them for good. Let's talk about it. Personal Growth is a Proven Satisfaction Booster We saw some come out in 2022 that essentially proves the life-changing benefits of stretching your perceived limits. exciting research There were two groups involved – the control group just had to keep a journal of their activities, but the test group had to spend two weeks doing something outside their comfort zone. They had complete agency over choosing the activity, but it had to be out of the ordinary. By the end of the study, there was a distinct difference between the groups; those who had challenged themselves to try something new felt significantly more satisfied with their lives. We can trace this back to a few likely factors: 1. The participants could choose their activity, so they felt ownership over their choice and therefore had a greater sense of agency. 2. There was a sense of fulfillment in achieving something they hadn't considered or felt confident to attempt before. 3. They were able to break down some of their limiting beliefs and see beyond their self-imposed limits. We are an evolved species for a reason; we're not built to stagnate. Humans should be in a constant state of learning, growing, and exploring beyond our horizons. But if we know it's good for us, why do we stay still? When Comfort Leads to Stagnation There's a reason why we call it the 'comfort zone' – it provides total comfort. At least, it provides comfort at first. Let's look at this through the lens of an example most of us can relate to: staying in a mediocre job. When you stay in a job you've been in for years, there's an element of comfort keeping you there. You know the people. You know the tasks inside and out. You're comfortable and confident in what you're doing. It's perfectly fine to stay in a job you enjoy. But what if you don't actually enjoy it anymore? What if there's a toxic team member bringing you down, or the work simply isn't challenging enough? Sometimes, the comfort compels us to stay regardless. The thought of starting all over again is daunting. Why leave when you're coping well enough here? This is where comfort becomes a double-edged sword. Too much of it, and it begins to work against us. That same job that was so comfortable at first slowly turns into monotony; boredom sets in, and our productivity suffers as a result. The Psychology of Staying Put On a neurological level, we are hardwired to avoid pain. We're not built to embrace it by default. By pain, I'm talking about all aspects – not just physical pain but anxiety, heartache, disappointment, depression, sadness, discomfort, anger. All of it. Since pain of any kind is our body's way of saying, "Hey, this is dangerous!" it's no wonder we try to avoid it. It's not wrong to do so, either; in fact, that pain avoidance is a part of our survival instinct. Without it, we'd be unable to protect ourselves from harm and survive as long as humans have done for centuries. research shows But we're at a point in our evolution where we need to bring a level of logic and reasoning into this. It's not as simple anymore; for instance, anxiety can arise from situations that are in no way threatening to our survival. We need to confront our fears and anxieties head-on, see where exactly they're coming from, and then make the conscious choice to move forward anyway. The Role of Self-Limiting Beliefs A huge element that plays into all of this is our self-limiting beliefs. Yes, we are mostly trying to avoid pain and discomfort wherever we can – but sometimes, we don't even believe in ourselves enough to try. How often do you get partway into a new workout schedule and drop it altogether? How many times have you vowed to start a meditation habit, only to give up after a few days? On a more serious note, how many relationships have you avoided because you don't believe you're worthy or prepared to receive that love? What jobs have you failed to apply for because you "probably won't get it anyway"? It's crazy to think that, as humans, we're capable of pretty much anything. It's the narratives we tell ourselves that actually stop us from reaching new heights. Where Self-Limitations Come From It's completely understandable that you're skeptical of this concept – after all, nobody likes to think they're the one holding themselves back. The truth is we all have stories and beliefs about ourselves that are ingrained in us since childhood. Those formative years end up writing the stories we tell ourselves down the track. If you didn't get the love and support you needed from your caregivers, it's not unusual to feel unworthy of love as an adult. If you were told from a young age that you wouldn't amount to much, everything might feel out of your reach. This is where shadow work and inner child therapy are incredibly helpful. When you trace your limitations back to their source, you'll start to wonder – could I actually move past these blockages? If they're just a narrative, what's stopping me? Why You Must Leave Your Comfort Zone (At Some Point) Being free to make your own choices is a blessing and a curse. No one is in your ear telling you what to do – but that means no one is going to push you unless do. you Why should you push yourself, then? What's the prize for making yourself uncomfortable on purpose? Well, as we saw from the study discussed earlier, you'll always be happier in that sweet spot just outside your comfort zone. Here, you'll find the fulfillment of trying something new and the joy that comes from achieving it. You'll also start to see just how capable you are – that all those self-limiting beliefs were there for no reason other than conditioning and socialization. You're much more powerful than you think; it's just a matter of tapping into that power and using it to shape your life in new ways. A Powerful Visualization Exercise In all my pursuits of self-development, I've done a lot of work to get out of the comfort zone. I've tried plenty of exercises – but the one that stands out for me is a very simple visualization. This involves a daily journal. You can do it any time, but I prefer to do it in the mornings to set each day's trajectory. All you are doing is picturing yourself ten years down the track. But this is not a manifestation exercise; you're not imagining how you to look or where you to be. You are imagining how you be based on the actions you're currently taking. want want will For example: say you've fallen off the bandwagon with your exercise routine, you're not looking after your mind and body, and you haven't been spending time with friends. Then you imagine yourself in ten years, and you will see that version of yourself if those habits don't change. You'll be out of shape, perhaps a bit depressed, and feeling quite lonely. But then – the magic part – you switch it up again and imagine what would happen if you started working on all these areas today. It compels you to carve out some time for those habits because you don't want that future version of yourself to ever exist. I much prefer this approach to anything else because it's a gradual, granular process. You're basing the events of each day on the person you want to be in the future. It's really that simple. Small, Consistent Steps Over Giant Sporradic Leaps Another approach I'll suggest here is moving out of your comfort zone slowly. There's no need to climb Mount Everest if you hate snow and heights. There's no need to quit your job and move to the other side of the world. Since challenging yourself is a muscle, and muscles build over time, it's better to take this slowly. If you want to get out there and be more social, for instance, maybe you'll start by messaging someone you grew apart from. Perhaps you could invite a friend for coffee. Eventually, you can build up to making entirely new friends at networking events – but it doesn't have to be straight away. What you want to avoid is these giant leaps that are so big you never actually follow through. Pushing yourself really does get easier with time, so trust the process. One step at a time. When Comfort Is Exactly What You Need As we draw to a close, I want to make something very clear. There will be times throughout your life when staying comfortable is your only option. Tragedy can strike us in many ways, whether it's being let go, losing a loved one, or falling out of a relationship. Life can be cruel when we least expect it. It's in these periods of life that wrapping ourselves in a protective cocoon may be best. Not forever, of course – the transition to a butterfly after a period of dormancy is a beautiful thing. But healing is a part of life that we need to make room for. I don't call these moments stagnant. They are times of much-needed stillness. When we're ready, we can decide to face the world again and start challenging ourselves . for our own benefit Wrap Up Are you feeling ready to start pushing against those boundaries? I hope so – because it can be completely life-changing. The key is to start small and build up; don't expect overnight success, but rather bask in the glory of becoming a different version of yourself each day. It's an incredible process that will open up new opportunities you never knew existed before. Remember – no growth in the comfort zone, and no comfort in the growth zone! But with slow and steady steps, you'll find yourself on top of the world soon enough. If you enjoyed this article, I’d love to hear from you. Write me at or at me and I’ll do my best to get back to everyone! scott@scottdclary.com tweet @ScottDClary Also published here .

The Psychology of Staying Put — And How to Branch Out of It

The Story-book of Science by Jean-Henri Fabre, is part of the HackerNoon Books Series. You can jump to any chapter in this book here . FRUIT CHAPTER LX. FRUIT “IT would be knowing a person very little only to be aware of his wearing a garment of a certain material, a coat of such and such a cloth. One does not know a flower any better when one knows that it is clothed with a calyx and a corolla. What is under this covering? A flowering branch of the Gillyflower “Let us examine together this gillyflower. It has a calyx of four sepals and a corolla of four yellow petals. I take away these eight pieces. What is left now is the essential part; that is to say, the thing without which the flower could not fill its rôle and would be perfectly useless. Let us go carefully over this remaining part. You will find it well worth the trouble. “First, there are six little white rods, each one surmounted by a bag full of yellow powder. These six pieces are called stamens. They are found in all flowers in greater or less number. The gillyflower has six, four longer ones arranged in pairs, and two shorter. “The double bag that surmounts the stamen is called an anther. The dust contained in the anther is known as pollen. It is yellow in the gillyflower, lily, and most plants; ashy gray in the poppy.” “You have already told us,” Jules interposed, “how clouds of pollen, raised by the wind in the woods, are the cause of supposed showers of sulphur that frighten people so.” “I take away the six stamens. There remains a central body, swollen at the bottom, narrow at the top, and surmounted by a kind of head wet with a sticky moisture. In its entirety this central body takes the name of pistil; the swelling at the bottom is called an ovary, and the sticky head that terminates it is a stigma.” “What big names for such little things!” exclaimed Jules. “Little, yes; but of unparalleled importance. These little things, my dear friend, give us our daily bread; without the miraculous work of these little things we should die of hunger.” “I will take care to remember their names, then.” “I, too,” chimed in Emile; “but you must go over them again, they are so hard to learn.” Uncle Paul began again. Jules and Emile repeated after him: stamen, anther and pollen; pistil, stigma and ovary. “With a penknife I divide the flower in two. The split ovary shows us what is inside.” “I see little seeds in regular rows in two compartments,” observed Jules. “Do you know what those hardly visible seeds are?” “Not yet.” “They are the future seeds of the plant. The ovary, then, is the part of the plant where the seeds form. At a certain time the flower withers; the petals wilt and fall; the calyx does the same, or remains to play the part of protector a while longer; the dried stamens break off; only the ovary remains, growing larger, ripening, and finally becoming the fruit. “Every fruit—the pear, apple, apricot, peach, walnut, cherry, melon, strawberry, almond, chestnut—began by being a little swelling of the pistil; all these excellent things that the plant furnishes us for food were first ovaries.” “A pear began by being the ovary of a pear blossom?” “Yes, my child; pears, apples, cherries, apricots, begin by being the ovaries of their respective flowers. I will show you an apricot in its blossom.” Uncle Paul took an apricot blossom, opened it with his penknife, and showed the children what is here shown in the picture. “In the heart of the flower you see the pistil surrounded by numerous stamens. The head that terminates it at the top is the stigma; the swelling at the bottom is the ovary or future apricot.” “That little green thing would have been an apricot, full of sweet juice, that I like so much?” inquired Emile. “That little green thing would have become an apricot like those Emile is so fond of. Now would you like to see the ovary that gives us bread?” “Oh, yes! All these things are very curious,” replied Jules. “Better than that, very important.” Claire gave her uncle a needle at his request; then with the delicate patience necessary for this operation he isolated one of the numerous flowers of which the whole forms the ear of wheat. The delicate little flower displayed clearly, on the point of the needle, the different parts composing it. Wheat “The blessed plant that gives us bread has not time to think of its toilet. It has such weighty things to attend to: it must feed the world! So you see what quiet clothes it wears! Two poor scales serve it for calyx and corolla. You can easily recognize three hanging stamens with their double sachets for anthers. The principal body of the flower is the tun-bellied ovary, which, when ripe, will be a grain of wheat. It is surmounted by the stigma, fashioned like a double plume of exquisite delicacy. Salute it, my children: behold the modest little flower that gives life to us all!” About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Jean-Henri Fabre (2018). The Story-book of Science. Urbana, Illinois: Project Gutenberg. Retrieved https://www.gutenberg.org/cache/epub/56795/pg56795-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html.

A flowering branch of the Gillyflower

The Noonification: Are Feature Branches the Ultimate Way to Go? (5/20/2023)

The common workflow for git (git flow) uses feature branches, where a separate branch is created for each new feature. Developers implement new functionality on these isolated branches and then merge their changes back into the or branch. main master The benefits of that workflow are clear: a separate branch can be conveniently deployed and tested in the QA environment, and if critical bugs are detected, it simply won’t get merged into the branch. Issues can be fixed and code improved in the same branch. main Meanwhile, the main branch remains constantly deployable and protected from that issues. Unfortunately, this strategy has a significant downside – merge conflicts. With long-living branches, which are at some point inevitable, these conflicts can be too difficult to resolve that it becomes easier to get rid of the branch altogether and start from scratch. As well, when it's many conflicts, the merge result may be unpredictable. However, it's not the only possible strategy, and this article will cover an alternative way to manage new product features without the disadvantages listed above. Why Do Merge Conflicts Occur? According to Git design, merge conflicts happen during merge when branches have different content in the same file line. To illustrate this, let's consider a scenario where two teams are implementing updates to the same service. Team A is integrating credit card support, while Team B is revamping the user profile page. It seems that these features have nothing to do with each other. However, it turns out that the payment-related code was previously located in the same place as the profile page code. So both teams extracted their code into separate branches and rewrote the integration. Now the question is, who will be the first to merge their changes into the branch and pretend that the problem is not on their side while the other team tries to resolve the resulting conflict? main Trunk-Based Development Altogether, avoiding merge conflicts is impossible, but we can certainly make them easier to resolve using the following well-known rule: If an action is difficult and scary, do it more often In Git terms, this would mean we need to merge as frequently as possible (ideally on every commit). And of course, conflicts will happen more often in that case, but resolving them will be much easier. It's called trunk-based development and means pushing changes directly to the branch and avoiding using branches when unnecessary. main In the example above, if both teams regularly pushed their changes to the branch, they would quickly notice they were trying to modify the same file. main Even more, they could have avoided issues altogether. The second team would have started making their changes after the first team had already modified the file, considering those updates. An attentive reader might wonder: everything sounds great, but how do we go about testing? Branches per feature allow testing the entire new functionality in isolation before the release; if we continuously integrate changes into the branch, there will be no chance for that. main Introducing Feature Flags A feature flag, or a feature toggle, is a simple dynamic flag that allows toggle the particular feature in runtime. Commonly, feature flags also allow enable or disable features for specific groups of users, like QA engineers, staff, specific customers, etc. The feature flags have several extra advantages: Risk-free deploy More reliable testing directly in production Quickly roll back changes when required. Using feature flags make pushing changes to the branch safer. While the feature flag is turned off, the changes don't affect anyone. main This technique allows working directly with the branch or creating short-living branches. So, the merge conflicts become pretty rare and resolve quickly. main Conclusion In summary, trunk-based development combined with feature flags is an excellent technique that helps avoid many problems prompted by conflicting changes in feature branches. However, as always, there is no one-size-fits-all. It works for a small number of teams that are working in the same repository – increasing this number usually requires some adjustments. Moreover, it's always possible to use both methods: use feature branches or feature flags depending on the specific situation and task.

Are Feature Branches the Ultimate Way to Go?

ফিচার শাখাগুলি কি যাওয়ার চূড়ান্ত উপায়?

Sind Feature Branches der ultimative Weg?

¿Son las ramas de características la forma definitiva de hacerlo?

Les branches de fonctionnalité sont-elles la solution ultime ?

क्या फ़ीचर शाखाएँ जाने का अंतिम तरीका हैं?

機能ブランチは究極の手段なのでしょうか?

기능 분기가 궁극적인 방법입니까?

As ramificações de recursos são o melhor caminho a seguir?

Özellik Dalları Gidilecek Nihai Yol mu?

Các nhánh tính năng có phải là cách cuối cùng để đi không?

功能分支是最终的选择吗？

Opportunities in Engineering by Charles M. Horton is part of the HackerNoon Books Series. You can jump to any chapter in this book here . THE FOUR MAJOR BRANCHES THE FOUR MAJOR BRANCHES The four major branches of engineering are civil, mechanical, electrical, and mining. I give them in the order of their acceptance among engineers. Each is separate from each of the others, and each is a profession in itself, and as distinctive from each of the others as is the allopathic from the homeopathic among men of medicine, though not with quite the same distinction. Whereas the several groups of physicians seek to relieve pain and correct disorder by way of diversified channels, the several groups of engineers each work in a field of endeavor actively apart from each of the other groups. Sometimes one group will lap over upon another group, in certain kinds of construction work, but even then the branches will hold sharply each to its own. Civil engineering embraces, roughly, all work in the soil. The surveyor is a civil engineer. He constructs dams, builds viaducts, lays out railroads, and in the war, where he was known as a pioneer, he was responsible for all tunneling and trench projects, besides keeping the highways clear and the wire entanglements intact. Civil engineering is a profession which keeps its followers pretty well out in the open. A civil engineer will go long distances, and frequently must, in order to get to his work, and, having reached the scene of his labors, enters upon a rugged outdoor life in camp where he remains until the job is completed. The Panama Canal was a civil-engineering job—probably the largest of its kind ever undertaken—and its success, after failure on the part of another government, is a high tribute to the genius of our own civil engineers. Mechanical engineering is a profession whose medium of endeavor lies in the metals. Mechanical engineers shape things out of iron or steel or brass or other metal compositions, and put these things into engines or machines for service. All machinery, whether it be printing-presses or automobiles or steam-engines, is the work of mechanical engineers, though in the matter of automobiles this has become a profession by itself, one of the minor branches known as automotive engineering. The mechanical engineer as a rule works within doors, just as the civil engineer works out of doors, and his work, consequently, is more confining. In the pursuit of his profession he spends much of his time supervising the design of mechanical units, and is the one man responsible for correct construction and security against fracture of the machine itself when in operation. Actually the mechanical engineer has more opportunities in his daily routine for the exercise of his creative faculties than has any one of the other kinds of engineers, for the simple reason that no two machines even for the same purpose—speaking of types, always—are exactly similar in construction. Two lathes of like size and scope, if manufactured by two separate organizations, will be different in their minor features, and each in some particular will be the work of a mechanical engineer whose ideas are at variance with those of the mechanical engineer who designed the other type. Engineers, like doctors, often disagree, which accounts for the many different types of machinery serving the same purpose which are found on the market. Electrical engineering is, as its name implies, a profession embracing all construction whose basis is the electrical current. Any unit whatsoever, so long as it utilizes or eats up or carries forward a current of electricity, is the work of electrical engineers. The profession is a comparatively recent one perforce, owing to the fact that but very little of a practical nature was known about electricity until a very few years ago. The wonderful progress in this field made within the past twenty years is one of the marvels of the engineering profession. Dynamos, motors, arc-lights, alternating current, the X-ray—these are a few of the things which followers of the profession have created for the uses of mankind. The field is yet practically unexplored, and offers to engineering students an outlet for their energies—provided they enter this branch of engineering—second to none of the other branches. A fascinating study, doubly so because of the fact that nothing is known about electricity itself—its effects only being understood—electrical engineering should appeal to the curious-minded as no other vocation can. It is a profession shrouded in mystery, and not the least mysterious of its recent developments is the wireless telegraph. What this one development alone holds for the future nobody can say. All sorts of inventions can be imagined, however, and among them I myself seem to see automobiles operated from central stations—indeed, all mechanical movements so operated—to the end that individual engines in time will cease to be. The profession of mining engineering, last of the major branches, embraces all work having to do with the locating and construction of mines—coal-mines, iron-mines, copper-mines, diamond-mines, gold-mines, and the like. Also it establishes the nature of the apparatus used, though more often than otherwise the mechanical engineer in this regard is consulted, since much of the machinery utilized in mining operations is the direct work of mechanical engineers. Screens and hoppers are mechanical devices the result of mechanical engineering genius; but the work of shoring up, done with timbers, and the work generally of supervision of all mine operations, rests solely with the mining man. The shaping of these timbers, though—the cutting of tenons, for instance—is the work, again, of the mechanical engineer; though the placing of these timbers, to revert back once more, is the work of the mining engineer. There are many minor branches, and more are rapidly coming into prominence. Chemical engineering is one of the older minor branches; while industrial engineering—following closely upon automotive engineering—belongs properly with the more recent of the newcomers. Efficiency engineering is a branch which to-day is making a strong bid for recognition as a profession, although the work as yet, lacking, as it does, proper foundation in scientific truth, even though strongly humanitarian in its motives, has still to prove itself acceptable among the engineering groups. Structural engineering, on the contrary, "belongs." Its work consists of the design and layout of modern steel structures—this roughly—while the minor branch known as heating and ventilating engineering, as its name would indicate, deals with the proper heating and ventilating of buildings, and as a profession is closely allied with that of structural engineering. Out of these minor branches come yet other branches, more particularly groups, with each in the nature of a specialty, such as gas engineering, aircraft engineering, steam engineering, telephone engineering, and so on. Students about to enter engineering colleges usually select one or another of the major branches and then after graduating begin to specialize. But infrequently Fate has much to do with this specialization, since after leaving college the average young engineer will turn to the nearest or most promising vacancy offered him in his chosen field—a major branch—and in the work eventually become expert and a specialist. If it be a concern manufacturing steam-turbines, say, the young engineer in time becomes expert and a specialist in steam-turbines. So, too, with graduates in mining engineering, in electrical engineering, in civil engineering, although the opportunities for specialization in any of these latter branches are not so good as in the mechanical field. However, entering upon a certain kind of work, the student usually follows this work to the end of his days, which is probably what engineering schools expect. All strive to educate only in the principles of each of the major branches. The rest is up to the graduate, who is permitted, and generally does, the shaping of his own career afterward. It is a feature of our democratic form of government—thanks be! Germany does—or did—the other thing. Germany made careers for her young men, instead of young men for careers, with the result that she also made machines out of them. America is a nation of individualists, which is what makes America what it is, and our schools and school systems are responsible. About HackerNoon Book Series: We bring you the most important technical, scientific, and insightful public domain books. This book is part of the public domain. Charles M. Horton (2008). Opportunities in Engineering. Urbana, Illinois: Project Gutenberg. Retrieved October 2022 https://www.gutenberg.org/cache/epub/24681/pg24681-images.html This eBook is for the use of anyone anywhere at no cost and with almost no restrictions whatsoever. You may copy it, give it away or re-use it under the terms of the Project Gutenberg License included with this eBook or online at www.gutenberg.org , located at https://www.gutenberg.org/policy/license.html .

Stories, News & Mentions about BRANCH

Branch’s Stories on HackerNoon