Difference between revisions of "Team:Valencia UPV/pruebaSeminarioBlack6"
| Line 28: | Line 28: | ||
<link href="https://fonts.googleapis.com/css?family=Lato:400,700,900" rel="stylesheet"> | <link href="https://fonts.googleapis.com/css?family=Lato:400,700,900" rel="stylesheet"> | ||
<link href="https://2018.igem.org/Template:Valencia_UPV/fontAwesome?action=raw&ctype=text/css" rel="stylesheet" type="text/css"> | <link href="https://2018.igem.org/Template:Valencia_UPV/fontAwesome?action=raw&ctype=text/css" rel="stylesheet" type="text/css"> | ||
| − | |||
| Line 59: | Line 58: | ||
height: 100%;margin-top: 4em;"> | height: 100%;margin-top: 4em;"> | ||
<div id="logoPrinteria" class="item" style=" | <div id="logoPrinteria" class="item" style=" | ||
| − | background-image: url(https://static.igem.org/mediawiki/2018/ | + | background-image: url(https://static.igem.org/mediawiki/2018/3/3d/T--Valencia_UPV--SoftwareFondoUPV2018.jpeg); |
height: 100%; | height: 100%; | ||
| − | width: 100%;background-attachment: fixed;background-size: cover;"><img src="https://static.igem.org/mediawiki/2018/thumb/ | + | width: 100%;background-attachment: fixed;background-size: cover;"><img src="https://static.igem.org/mediawiki/2018/thumb/c/c0/T--Valencia_UPV--SoftwareTextoUPV2018.jpeg/1200px-T--Valencia_UPV--SoftwareTextoUPV2018.jpeg.png" style=" margin-top: 0px;"> |
<a class="btn down inner-link active" href="#story" style="font-size: 82%;right: 50%;/* position: fixed; *//* bottom: 7%; */top: 85.2%;z-index: 99;background-color: white;position: absolute;border-radius: 80%;width: 3.8em;height: 3.8em;padding: 0;padding-top: 14px;"> | <a class="btn down inner-link active" href="#story" style="font-size: 82%;right: 50%;/* position: fixed; *//* bottom: 7%; */top: 85.2%;z-index: 99;background-color: white;position: absolute;border-radius: 80%;width: 3.8em;height: 3.8em;padding: 0;padding-top: 14px;"> | ||
<i class="stack-interface stack-down-open-big"></i> | <i class="stack-interface stack-down-open-big"></i> | ||
</a> | </a> | ||
| − | </div> | + | </div> |
| − | + | ||
| − | + | ||
</div> | </div> | ||
| − | |||
</center> | </center> | ||
| − | |||
</div><div class="all-page-modals"></div><div class="all-page-modals"></div> | </div><div class="all-page-modals"></div><div class="all-page-modals"></div> | ||
<div class="all-page-modals"></div> | <div class="all-page-modals"></div> | ||
</section> | </section> | ||
| − | + | </div> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
<a class="anchorOffset" id="story"></a> | <a class="anchorOffset" id="story"></a> | ||
<section class="feature-large" style="padding-top: 6em; padding-bottom: 50px; outline: none;" data-scroll-id="story" tabindex="-1"> | <section class="feature-large" style="padding-top: 6em; padding-bottom: 50px; outline: none;" data-scroll-id="story" tabindex="-1"> | ||
<div class="container"> | <div class="container"> | ||
| − | + | <div class="row"> | |
| − | + | <div class="col-md-3" style=" | |
| − | + | margin-left: 0em; | |
| − | + | padding-right: 0px; | |
| − | + | padding-left: 0.2em;"> | |
| − | + | <div class="tabs-container tabs--vertical page-navigator" style="position: -webkit-sticky;position: sticky;padding-bottom: 0px;margin-top: 11.4em;"> | |
| − | + | <h4 style=" | |
| − | + | padding-left: 1em; | |
| − | + | ">Index</h4> | |
| − | + | <ul class="lateral"> | |
| − | + | <li class="lateral"> | |
| − | + | <div class="tab__title" style=" | |
| − | + | line-height: 1.3em; | |
| − | + | "> | |
| − | + | <a href="#models" class="lateral inner-link" style=" | |
| − | + | color: #353535; | |
| − | + | opacity: 1; | |
| − | + | ">Models & Experiments</a> | |
| − | + | ||
| − | + | </div> | |
| − | + | </li> | |
| − | + | <li class="lateral"> | |
| − | + | <div class="tab__title" style=" | |
| − | "> | + | line-height: 1.3em; |
| − | <a href="# | + | "> |
| − | + | <a href="#simtool" class="lateral inner-link" style=" | |
| − | + | color: #353535; | |
| − | + | opacity: 1; | |
| − | + | ">Simulation Tool</a> | |
| − | + | </div> | |
| − | + | </li> | |
| − | + | <li class="lateral"> | |
| − | + | <div class="tab__title" style=" | |
| + | line-height: 1.3em; | ||
| + | "> | ||
| + | <a href="#references" class="lateral inner-link" style=" | ||
| + | color: #353535; | ||
| + | opacity: 1; | ||
| + | ">References</a> | ||
| + | </div> | ||
| + | </li> | ||
| + | <!--</ul> | ||
| + | <ul class="tabs-content">--> | ||
| + | </ul> | ||
| + | </div> | ||
</div> | </div> | ||
| − | + | <div class="col-md-9 col9Attr" style="padding-left: 6em;padding-right: 2em;"> | |
| − | <div class="col-md-9 | + | <div> |
| − | + | <a class="anchorOffset" id="Intro"></a> | |
| − | + | <h3>Printeria Controller</h3> | |
| − | + | ||
| − | + | <p> | |
| + | When it comes to automating the process of designing and printing genetic circuits in the lab, there is no denying that Printeria facilitates those tasks for both the average and the experienced user. But, without an interface to define all the necessary parameters, keep track of the device’s inventory, and monitor all of the steps of the process, that would not be possible. | ||
| − | + | </p> | |
| + | <p> | ||
| + | We aim to solve that with Printeria Controller, an intuitive software that provides a user-friendly interface meant for all kinds of users, so that everyone can have access to the capabilities of Printeria. This controller help us to achieve the goal of our project: Make synthetic biology easier. | ||
| − | + | </p> | |
| + | <h3>Design Considerations</h3> | ||
| + | <h4> A web application </h4> | ||
| + | <p>Scientists nowadays use computers in the lab to take notes of their experiments, do research, make measurements from the laboratory devices… So we thought, why don’t they also use Printeria from the lab computer? That way, extra devices won’t be necessary. Once that decision was made, we found a setback: installing software in the computer and setting it all up can be very time-consuming, and sometimes scientists rely on a system administrator in order to do so. That’s why we opted for a web application implemented in a Raspberry PI inside Printeria. This approach, solved both the problem of installing the software and the problem of administering it in several computers, because once it’s installed, it will only be necessary to monitor the server. </p> <p>When deciding which set of technologies will suit best this kind of application, we had several options in mind, and the key aspects we were searching for were:</p><ul style=" | ||
| + | padding-bottom: 2e; | ||
| + | font-size: 16px;"><li>Modern technologie</li><li>Reduced computational workload</li><li style=" | ||
| + | padding-bottom: 1em;">The use of versatile programming languages.</li></ul><p>That’s why we chose the MEAN stack, an open source framework to develop dynamic web applications. This framework, backed by google, provides a highly reliable and scalable infrastructure, and all the components of the stack are compatible with JavaScript, one of the most used programming languages nowadays. </p><p>The MEAN stack is composed of MongoDB, Express.js, Angular.js and Node.js. With all those technologies we were able to develop all the layers of our application from the client-side to the server-side with ease and flexibility.</p><p></p> | ||
| + | <p> | ||
| + | We used MEAN stack, an open source framework to develop dynamic web applications in JavaScript. We chose this technology because it is very flexible, it allowed us to test and upload the application in the cloud easily, and because it uses only one language, JavaScript, both in the server-side and the client-side, wich made it very fast to develop. | ||
| + | </p> | ||
| − | + | <p> | |
| + | It’s composed with MongoDB, our database, Express.js, a web application framework for Node.js, Angular.js, that runs in the browser JavaScript, and Node.js, where server-side is executed in JavaScript outside the browser. | ||
| + | </p> | ||
| − | + | <h4>Definition of Requirements</h4> | |
| − | + | ||
| − | + | <p> | |
| − | + | We used SCRUM, an agile framework to improve productivity. We talked and discussed with biotechnologists and possible users about what features would the controller be useful to have, and we listed them in a backlog, categorizing them by priority. Then the computer scientist decided the amount of work required for the first sprint. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | </p> | ||
| + | <p> | ||
| + | Every week a meetup was made to update to all the team the progress that was made and to generate feedback in order to apply changes if needed. Once we achieved the goals of each sprint, we decided new backlog features to add to the software. This way, we achieved the team and user satisfaction because they saw the breakthrough and they could actively get involved in the development. | ||
| + | </p> | ||
| − | + | </div> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | <div> | |
| − | + | <a class="anchorOffset" id="Req"></a> | |
| − | + | ||
| − | + | <h3> Software flow </h3> | |
| − | + | <p> | |
| − | + | When the user first access to Printeria Controller he has to register in order to have a registry of all of his experiments and save his configurations to ease future printings. We decided it would be useful for the user to know which person has done a determinate job in the past, see whose job is now being printed or before his, and adjust a specific configuration for the experiments so every time he wants to print something he would not have to configure it again, Printeria Controller does for him. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | </p> | |
| − | + | <p> | |
| − | + | Once he is registered, he would be able to create a “New Job”, a genetic circuit, entering a name and a description for the experiment. He can choose from a wide variety of parts allocated in our database to design a Transcriptional Unit. This parts are represented following the SBOL standard visual symbols. Information about the parts such "p" or "dm" is displayed in the info button if it is needed. More advanced options are provided, such as cycle configuration, in the “Advanced Mode”. With these options the user will be able to select the exact sequence of cycles, the time spent on each of the zones and the temperature, thus defining the instructions for the droplets. | |
| − | + | </p> | |
| − | + | ||
| − | + | <p> | |
| + | When all the data about the experiment is fulfilled, a modelling simulation can be made before the experiment starts. First of all, the software will collect all the necessary information about the experiment and will create a string to be sent through all the layers of the application till it reaches the Backend. Here, a python script will be executed and all the data will be generated. Finally, after the modeling results have been stored, a link to their location will be sent to the Frontend in order to be displayed in dynamic charts, giving the user the possibility to download or print them. | ||
| + | </p> | ||
| − | + | <p> | |
| − | + | Among the printeria options, the possibility of save the genetic circuit in a public recipes repository stands out. This repository is full of recipes added by Printeria users that can be printed in our device at any time. The recipes contain all the information about already made experiments and the results that were obtained, including charts added by the user after an experiment has been done, dates of the experiments, number of times they have been replicated and of course information about the biological parts used. Those recipes can also be quickly printed if it is needed to add them to a report, for example. | |
| − | + | </p> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | <p> | ||
| + | Recipes can be very useful for non-scientific users. They can just search easily a functionality that they want the bacteria to express, for example a fluorescent red bacteria, and just send it to print. Bio artists can benefit from this functionality, as well as students who want to recreate an experiment done by their teacher. | ||
| + | </p> | ||
| − | + | <p> | |
| − | + | After a recipe or a job has been selected to be printed, the inventory will be checked in order to confirm that the experiment can be executed with the available parts. | |
| + | </p> | ||
| + | |||
| + | <p> | ||
| + | The inventory provides a graphical representation of the wheel that can be found inside of our device, Printeria, with all the cartridges and their contents. The content of the cartridges can be modified, refilled and deleted in order to reflect the changes that are made in the real wheel. | ||
| + | </p> | ||
| − | + | <p> | |
| − | + | The wheel distribution is the following: | |
| − | + | </p> | |
| + | <ul> | ||
| + | <li>3 for promoters. </li> | ||
| + | <li>3 for RBSs.</li> | ||
| + | <li>4 for CDSs.</li> | ||
| + | <li>2 for terminators. </li> | ||
| + | <li>2 for bacteria.</li> | ||
| + | <li>2 for buffers.</li> | ||
| + | <li>4 for enzima.</li> | ||
| + | <li>6 for water and alcohol.</li> | ||
| + | </ul> | ||
| − | + | <p> | |
| − | + | The wheel cartridge distribution was made accordingly to Printeria needs and capabilities. We were aware that the parts couldn’t remain much time at room temperature, and because our hardware device nowadays doesn’t have a refrigerator, the maximum number of parts that could remain on it are two, given that one reaction takes ~4 hours. Nevertheless this fact, we added extra holes for cartridges to add them when they are needed if they are preserved in a refrigerator until the job is sent to be printed. Additionally, water and alcohol cartridges are included to clean the surface of the PCB automatically after every reaction. | |
| − | + | </p> | |
| − | + | <p> | |
| − | + | The inventory also gives the user the possibility to include parts in the repository either one by one with user-friendly forms for each of the parts or all at once by using a csv (comma-separated values) processing script, allowing the user to load thousands of parts and recipes. The usual workflow would be defining all the parts or recipes to be stored beforehand in Microsoft Excel or another spreadsheet software following the format guidelines, exporting the file in csv format, pasting the contents of the file inside the text form and selecting the type of content to be introduced: Recipes, Promoters, RBSs, CDSs or Terminators. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | </p> | |
| + | <p> | ||
| + | After a recipe or a job has been sent to be printed, it will be placed in the job queue. This way, the user can follow the experiment and see in real-time how it goes through all the steps of the process. | ||
| + | </p> | ||
| + | <p> | ||
| + | In order to manage the job queue and the communication with the device, we have implemented a heartbeat mechanism. When Printeria Controller is started for the first time, a script is executed, and it will remain sending periodic signals till the device is turned off. This way, we have been able not only to control that the job queue does all the necessary checks before printing a job, but also to retrieve all the information sent from the device and to store it, everything done automatically. | ||
| − | + | </p> | |
| + | <p> | ||
| + | When the job has just entered the job queue, it is marked as “To Do”, allowing the user to make modifications or delete the job. When there are no jobs in execution, the next job is dequeued and the printing process can start, thus being marked as “Doing”, only giving the possibility to cancel it. After the job has been correctly printed, it will be marked as “Done”, and it will provide the generated results. | ||
| − | + | </p> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| + | </div> | ||
| − | + | ||
| + | <div> | ||
| + | <a class="anchorOffset" id="Future"></a> | ||
| + | <h3>Future</h3> | ||
| + | |||
| + | <p> | ||
| + | In future lines of development, we pretend to add more features in order to make a more powerful Controller. The most significant of them will be the possibility of a Level 2 assembly. In the New Job tab, users will be able to choose a second Transcriptional Unit as an extra element of the experiment, opening a wider range of possibilities. | ||
| + | </p> | ||
| + | <p> | ||
| + | The more data we have, the more precise our experiments can be. Therefore, if data about the experiments made in other Printerias was in our hands, apart of having a wider range of different experiments, we could achieve more precision at doing an specific experiment that has already been done by other scientists on their Printerias. That is one of our goals, improving the Recipes tab by adding recipes with information about results of experiments done in another Printeria. Thus, charts and statistics with the average results of experiments could be generated and consulted by the user. | ||
| + | </p> | ||
| + | |||
| + | <p> | ||
| + | When a biological part runs out it’s possible that the user wants to buy more of it for future experiments. We thought that would be very useful that the application offers the user prices of the element from different suppliers, so he can directly contact with them if he needs to. | ||
| + | </p> | ||
| + | <p> | ||
| + | Finally, to achieve a better user experience we will implement a functionality to send an e-mail to the user when its job is finished, because, maybe he is not in the lab at the moment, and that way he doesn’t have to worry about his job. | ||
| + | </p> | ||
| + | |||
| − | + | </div> | |
| + | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ||
| − | + | </div> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
</div> | </div> | ||
| − | </div></section> | + | </div> |
| + | </section> | ||
Revision as of 22:19, 16 October 2018
Printeria Controller
When it comes to automating the process of designing and printing genetic circuits in the lab, there is no denying that Printeria facilitates those tasks for both the average and the experienced user. But, without an interface to define all the necessary parameters, keep track of the device’s inventory, and monitor all of the steps of the process, that would not be possible.
We aim to solve that with Printeria Controller, an intuitive software that provides a user-friendly interface meant for all kinds of users, so that everyone can have access to the capabilities of Printeria. This controller help us to achieve the goal of our project: Make synthetic biology easier.
Design Considerations
A web application
Scientists nowadays use computers in the lab to take notes of their experiments, do research, make measurements from the laboratory devices… So we thought, why don’t they also use Printeria from the lab computer? That way, extra devices won’t be necessary. Once that decision was made, we found a setback: installing software in the computer and setting it all up can be very time-consuming, and sometimes scientists rely on a system administrator in order to do so. That’s why we opted for a web application implemented in a Raspberry PI inside Printeria. This approach, solved both the problem of installing the software and the problem of administering it in several computers, because once it’s installed, it will only be necessary to monitor the server.
When deciding which set of technologies will suit best this kind of application, we had several options in mind, and the key aspects we were searching for were:
- Modern technologie
- Reduced computational workload
- The use of versatile programming languages.
That’s why we chose the MEAN stack, an open source framework to develop dynamic web applications. This framework, backed by google, provides a highly reliable and scalable infrastructure, and all the components of the stack are compatible with JavaScript, one of the most used programming languages nowadays.
The MEAN stack is composed of MongoDB, Express.js, Angular.js and Node.js. With all those technologies we were able to develop all the layers of our application from the client-side to the server-side with ease and flexibility.
We used MEAN stack, an open source framework to develop dynamic web applications in JavaScript. We chose this technology because it is very flexible, it allowed us to test and upload the application in the cloud easily, and because it uses only one language, JavaScript, both in the server-side and the client-side, wich made it very fast to develop.
It’s composed with MongoDB, our database, Express.js, a web application framework for Node.js, Angular.js, that runs in the browser JavaScript, and Node.js, where server-side is executed in JavaScript outside the browser.
Definition of Requirements
We used SCRUM, an agile framework to improve productivity. We talked and discussed with biotechnologists and possible users about what features would the controller be useful to have, and we listed them in a backlog, categorizing them by priority. Then the computer scientist decided the amount of work required for the first sprint.
Every week a meetup was made to update to all the team the progress that was made and to generate feedback in order to apply changes if needed. Once we achieved the goals of each sprint, we decided new backlog features to add to the software. This way, we achieved the team and user satisfaction because they saw the breakthrough and they could actively get involved in the development.
Software flow
When the user first access to Printeria Controller he has to register in order to have a registry of all of his experiments and save his configurations to ease future printings. We decided it would be useful for the user to know which person has done a determinate job in the past, see whose job is now being printed or before his, and adjust a specific configuration for the experiments so every time he wants to print something he would not have to configure it again, Printeria Controller does for him.
Once he is registered, he would be able to create a “New Job”, a genetic circuit, entering a name and a description for the experiment. He can choose from a wide variety of parts allocated in our database to design a Transcriptional Unit. This parts are represented following the SBOL standard visual symbols. Information about the parts such "p" or "dm" is displayed in the info button if it is needed. More advanced options are provided, such as cycle configuration, in the “Advanced Mode”. With these options the user will be able to select the exact sequence of cycles, the time spent on each of the zones and the temperature, thus defining the instructions for the droplets.
When all the data about the experiment is fulfilled, a modelling simulation can be made before the experiment starts. First of all, the software will collect all the necessary information about the experiment and will create a string to be sent through all the layers of the application till it reaches the Backend. Here, a python script will be executed and all the data will be generated. Finally, after the modeling results have been stored, a link to their location will be sent to the Frontend in order to be displayed in dynamic charts, giving the user the possibility to download or print them.
Among the printeria options, the possibility of save the genetic circuit in a public recipes repository stands out. This repository is full of recipes added by Printeria users that can be printed in our device at any time. The recipes contain all the information about already made experiments and the results that were obtained, including charts added by the user after an experiment has been done, dates of the experiments, number of times they have been replicated and of course information about the biological parts used. Those recipes can also be quickly printed if it is needed to add them to a report, for example.
Recipes can be very useful for non-scientific users. They can just search easily a functionality that they want the bacteria to express, for example a fluorescent red bacteria, and just send it to print. Bio artists can benefit from this functionality, as well as students who want to recreate an experiment done by their teacher.
After a recipe or a job has been selected to be printed, the inventory will be checked in order to confirm that the experiment can be executed with the available parts.
The inventory provides a graphical representation of the wheel that can be found inside of our device, Printeria, with all the cartridges and their contents. The content of the cartridges can be modified, refilled and deleted in order to reflect the changes that are made in the real wheel.
The wheel distribution is the following:
- 3 for promoters.
- 3 for RBSs.
- 4 for CDSs.
- 2 for terminators.
- 2 for bacteria.
- 2 for buffers.
- 4 for enzima.
- 6 for water and alcohol.
The wheel cartridge distribution was made accordingly to Printeria needs and capabilities. We were aware that the parts couldn’t remain much time at room temperature, and because our hardware device nowadays doesn’t have a refrigerator, the maximum number of parts that could remain on it are two, given that one reaction takes ~4 hours. Nevertheless this fact, we added extra holes for cartridges to add them when they are needed if they are preserved in a refrigerator until the job is sent to be printed. Additionally, water and alcohol cartridges are included to clean the surface of the PCB automatically after every reaction.
The inventory also gives the user the possibility to include parts in the repository either one by one with user-friendly forms for each of the parts or all at once by using a csv (comma-separated values) processing script, allowing the user to load thousands of parts and recipes. The usual workflow would be defining all the parts or recipes to be stored beforehand in Microsoft Excel or another spreadsheet software following the format guidelines, exporting the file in csv format, pasting the contents of the file inside the text form and selecting the type of content to be introduced: Recipes, Promoters, RBSs, CDSs or Terminators.
After a recipe or a job has been sent to be printed, it will be placed in the job queue. This way, the user can follow the experiment and see in real-time how it goes through all the steps of the process.
In order to manage the job queue and the communication with the device, we have implemented a heartbeat mechanism. When Printeria Controller is started for the first time, a script is executed, and it will remain sending periodic signals till the device is turned off. This way, we have been able not only to control that the job queue does all the necessary checks before printing a job, but also to retrieve all the information sent from the device and to store it, everything done automatically.
When the job has just entered the job queue, it is marked as “To Do”, allowing the user to make modifications or delete the job. When there are no jobs in execution, the next job is dequeued and the printing process can start, thus being marked as “Doing”, only giving the possibility to cancel it. After the job has been correctly printed, it will be marked as “Done”, and it will provide the generated results.
Future
In future lines of development, we pretend to add more features in order to make a more powerful Controller. The most significant of them will be the possibility of a Level 2 assembly. In the New Job tab, users will be able to choose a second Transcriptional Unit as an extra element of the experiment, opening a wider range of possibilities.
The more data we have, the more precise our experiments can be. Therefore, if data about the experiments made in other Printerias was in our hands, apart of having a wider range of different experiments, we could achieve more precision at doing an specific experiment that has already been done by other scientists on their Printerias. That is one of our goals, improving the Recipes tab by adding recipes with information about results of experiments done in another Printeria. Thus, charts and statistics with the average results of experiments could be generated and consulted by the user.
When a biological part runs out it’s possible that the user wants to buy more of it for future experiments. We thought that would be very useful that the application offers the user prices of the element from different suppliers, so he can directly contact with them if he needs to.
Finally, to achieve a better user experience we will implement a functionality to send an e-mail to the user when its job is finished, because, maybe he is not in the lab at the moment, and that way he doesn’t have to worry about his job.