Td
T. de Boer
info
Please Note
<p>This page displays the records of the person named above and is not linked to a unique person identifier. This record may need to be merged to a profile.</p>
2 records found
1
Many development models exist, but finding which one is the right for a specific project or software company is difficult. Every project has its requirements and might need its own development model. The most popular development models are trunk-based development and merge requests.
There are no clear science-based guidelines on when to adopt one model or the other and challenges that teams face when migrating from one to another.
We perform a field study as this master thesis aims to provide more understanding on the impact of migrating from one development model to another at a large company. More specifically, a migration from trunk-based development to merge request-based development at a large software engineering company.
During this research, we interview 19 developers, eleven before the migration and eight after the migration, survey 46 developers to triangulate our findings of the interview before the migration, and analyzed the differences in the code reviews made by developers before and after the migration.
We show what benefits and challenges developers experience using the trunk-based model and what they expect from the merge request-based model before the migration. Also, we show the change of motivation for code reviews after the migration. Moreover, quantitative data shows that code reviews are completed faster and with more code comments in the merge request-based model. Finally, we provide the perceptions of developers after the migration. ...
There are no clear science-based guidelines on when to adopt one model or the other and challenges that teams face when migrating from one to another.
We perform a field study as this master thesis aims to provide more understanding on the impact of migrating from one development model to another at a large company. More specifically, a migration from trunk-based development to merge request-based development at a large software engineering company.
During this research, we interview 19 developers, eleven before the migration and eight after the migration, survey 46 developers to triangulate our findings of the interview before the migration, and analyzed the differences in the code reviews made by developers before and after the migration.
We show what benefits and challenges developers experience using the trunk-based model and what they expect from the merge request-based model before the migration. Also, we show the change of motivation for code reviews after the migration. Moreover, quantitative data shows that code reviews are completed faster and with more code comments in the merge request-based model. Finally, we provide the perceptions of developers after the migration. ...
Many development models exist, but finding which one is the right for a specific project or software company is difficult. Every project has its requirements and might need its own development model. The most popular development models are trunk-based development and merge requests.
There are no clear science-based guidelines on when to adopt one model or the other and challenges that teams face when migrating from one to another.
We perform a field study as this master thesis aims to provide more understanding on the impact of migrating from one development model to another at a large company. More specifically, a migration from trunk-based development to merge request-based development at a large software engineering company.
During this research, we interview 19 developers, eleven before the migration and eight after the migration, survey 46 developers to triangulate our findings of the interview before the migration, and analyzed the differences in the code reviews made by developers before and after the migration.
We show what benefits and challenges developers experience using the trunk-based model and what they expect from the merge request-based model before the migration. Also, we show the change of motivation for code reviews after the migration. Moreover, quantitative data shows that code reviews are completed faster and with more code comments in the merge request-based model. Finally, we provide the perceptions of developers after the migration.
There are no clear science-based guidelines on when to adopt one model or the other and challenges that teams face when migrating from one to another.
We perform a field study as this master thesis aims to provide more understanding on the impact of migrating from one development model to another at a large company. More specifically, a migration from trunk-based development to merge request-based development at a large software engineering company.
During this research, we interview 19 developers, eleven before the migration and eight after the migration, survey 46 developers to triangulate our findings of the interview before the migration, and analyzed the differences in the code reviews made by developers before and after the migration.
We show what benefits and challenges developers experience using the trunk-based model and what they expect from the merge request-based model before the migration. Also, we show the change of motivation for code reviews after the migration. Moreover, quantitative data shows that code reviews are completed faster and with more code comments in the merge request-based model. Finally, we provide the perceptions of developers after the migration.
Akka Decision Engine
An actor based decision engine on the DMN 1.1 specifications
Decision engines can decide from a certain input what the output should be. This is done in a table with columns for inputs and outputs and rows for a combination of inputs together with its corresponding output. A row is also called a rule. A simple program to decide such a decision table can easily be made, like Camunda. However, when the output of one table is also the input of another table and so on and the amount of rules get enormously big, the problem gets more complicated and Camunda takes a very long time to solve such structures.
We created a decision engine in Scala that can decide the output when there are thousands of tables linked together in less than a minute with the help of Akka. Akka is an actor model, which means that it can create multiple actors, which each can perform a certain task. Actors can run in parallel, which speeds up the decision engine. Actors send messages to each other and an actor will only start working when they receive a message. The decision engine reads DMN files and parses it to tables. For better performance the decision tables get parsed into a tree structure with for every table the input tables are its children. In this way the decision engine is very quick in solving tables, however the parsing into trees still takes some time. This is not a big problem, since the parsing is only done once and the tree can be saved and the solving can be done very often. Also the deciding of a single table is improved, because we created our own FEEL-expressions that can decide the rules very fast. The result is that after a very large table with 50,000 rules is parsed, the solving that took Camunda 400 milliseconds only takes 9 milliseconds for the new decision engine and when the parsing is left out, the new engine is faster in computing 500,000 rules than Camunda with 1 rule. Also when the parsing is included in the time, the difference gets only bigger. For 50,000 rules, Camunda takes 20 seconds to parse the file and solve the table, while the new decision engine takes only a little more than 1 second to do this all. When the files get larger, so does the difference. ...
We created a decision engine in Scala that can decide the output when there are thousands of tables linked together in less than a minute with the help of Akka. Akka is an actor model, which means that it can create multiple actors, which each can perform a certain task. Actors can run in parallel, which speeds up the decision engine. Actors send messages to each other and an actor will only start working when they receive a message. The decision engine reads DMN files and parses it to tables. For better performance the decision tables get parsed into a tree structure with for every table the input tables are its children. In this way the decision engine is very quick in solving tables, however the parsing into trees still takes some time. This is not a big problem, since the parsing is only done once and the tree can be saved and the solving can be done very often. Also the deciding of a single table is improved, because we created our own FEEL-expressions that can decide the rules very fast. The result is that after a very large table with 50,000 rules is parsed, the solving that took Camunda 400 milliseconds only takes 9 milliseconds for the new decision engine and when the parsing is left out, the new engine is faster in computing 500,000 rules than Camunda with 1 rule. Also when the parsing is included in the time, the difference gets only bigger. For 50,000 rules, Camunda takes 20 seconds to parse the file and solve the table, while the new decision engine takes only a little more than 1 second to do this all. When the files get larger, so does the difference. ...
Decision engines can decide from a certain input what the output should be. This is done in a table with columns for inputs and outputs and rows for a combination of inputs together with its corresponding output. A row is also called a rule. A simple program to decide such a decision table can easily be made, like Camunda. However, when the output of one table is also the input of another table and so on and the amount of rules get enormously big, the problem gets more complicated and Camunda takes a very long time to solve such structures.
We created a decision engine in Scala that can decide the output when there are thousands of tables linked together in less than a minute with the help of Akka. Akka is an actor model, which means that it can create multiple actors, which each can perform a certain task. Actors can run in parallel, which speeds up the decision engine. Actors send messages to each other and an actor will only start working when they receive a message. The decision engine reads DMN files and parses it to tables. For better performance the decision tables get parsed into a tree structure with for every table the input tables are its children. In this way the decision engine is very quick in solving tables, however the parsing into trees still takes some time. This is not a big problem, since the parsing is only done once and the tree can be saved and the solving can be done very often. Also the deciding of a single table is improved, because we created our own FEEL-expressions that can decide the rules very fast. The result is that after a very large table with 50,000 rules is parsed, the solving that took Camunda 400 milliseconds only takes 9 milliseconds for the new decision engine and when the parsing is left out, the new engine is faster in computing 500,000 rules than Camunda with 1 rule. Also when the parsing is included in the time, the difference gets only bigger. For 50,000 rules, Camunda takes 20 seconds to parse the file and solve the table, while the new decision engine takes only a little more than 1 second to do this all. When the files get larger, so does the difference.
We created a decision engine in Scala that can decide the output when there are thousands of tables linked together in less than a minute with the help of Akka. Akka is an actor model, which means that it can create multiple actors, which each can perform a certain task. Actors can run in parallel, which speeds up the decision engine. Actors send messages to each other and an actor will only start working when they receive a message. The decision engine reads DMN files and parses it to tables. For better performance the decision tables get parsed into a tree structure with for every table the input tables are its children. In this way the decision engine is very quick in solving tables, however the parsing into trees still takes some time. This is not a big problem, since the parsing is only done once and the tree can be saved and the solving can be done very often. Also the deciding of a single table is improved, because we created our own FEEL-expressions that can decide the rules very fast. The result is that after a very large table with 50,000 rules is parsed, the solving that took Camunda 400 milliseconds only takes 9 milliseconds for the new decision engine and when the parsing is left out, the new engine is faster in computing 500,000 rules than Camunda with 1 rule. Also when the parsing is included in the time, the difference gets only bigger. For 50,000 rules, Camunda takes 20 seconds to parse the file and solve the table, while the new decision engine takes only a little more than 1 second to do this all. When the files get larger, so does the difference.