Difference between revisions of "Team:UCL/Software"

Line 434: Line 434:
 
       </div>
 
       </div>
 
     </div>
 
     </div>
 +
 +
 
 
    
 
    
      <p>For more information, the source code, and the extension go to <a href="https://github.com/ucligem2015/Mind-The-Mark">
 
        Our Github Page.</a></p>
 
    <a href="https://github.com/ucligem2015/Mind-The-Mark" style="color:red;">
 
    <img src="https://static.igem.org/mediawiki/2015/3/32/UCLGitHubLogo.png" width="10%" style="margin:0 45%;"/>
 
    </a>
 
 
    
 
    
      <h3>Construction</h3>
+
    <h3>Construction</h3>
  
      <p>The spirit of the tool is to make editing and working on the iGEM wiki easier and more interactive for all.
+
    <p>The spirit of the tool is to make editing and working on the iGEM wiki easier and more interactive for all.
 
       It was with this spirit that we built the tool. Although the code is part of chrome extension, it is really
 
       It was with this spirit that we built the tool. Although the code is part of chrome extension, it is really
 
       a lightweight javascript tool.</p>
 
       a lightweight javascript tool.</p>
     
+
 
      <h3>What is a Chrome Extension?</h3>
+
    <h3>What is a Chrome Extension?</h3>
      <p>A chrome extension at its base is a <b>.json</b> file called the "Manifest" file that contains the file
+
    <p>A chrome extension at its base is a <b>.json</b> file called the "Manifest" file that contains the file
 
       reference's and basic information about the tool. When used this tells the browser to load a piece of javascript or other files  
 
       reference's and basic information about the tool. When used this tells the browser to load a piece of javascript or other files  
 
       on to specified pages. These then interact with the DOM (Document Object Model) of the page.</p>
 
       on to specified pages. These then interact with the DOM (Document Object Model) of the page.</p>
     
+
 
      <h3>Why use a Chrome Extension?</h3>
+
    <h3>Why use a Chrome Extension?</h3>
      <p>Chrome is one of the most modern and widely used browser on the internet and has an easy to use and develop
+
    <p>Chrome is one of the most modern and widely used browser on the internet and has an easy to use and develop
 
       extension system, on top of a very rich API. When loading files that interact with the DOM chrome extensions
 
       extension system, on top of a very rich API. When loading files that interact with the DOM chrome extensions
 
       also make sure that there is no interaction with any of the loaded scripts of libraries from the page, protecting
 
       also make sure that there is no interaction with any of the loaded scripts of libraries from the page, protecting
 
       the user. To top it all off, the chrome extensions are very easy to install and distribute.</p>
 
       the user. To top it all off, the chrome extensions are very easy to install and distribute.</p>
     
+
 
      <h3>How did we Implement it?</h3>
+
    <h3>How did we Implement it?</h3>
      <p>Our tool uses the commonly implemented "Content_Scripts" method for loading our extension. This allows
+
    <p>Our tool uses the commonly implemented "Content_Scripts" method for loading our extension. This allows
 
       chrome to load specific js and css files whenever a URL, defined by a certain patern, is loaded. In our case
 
       chrome to load specific js and css files whenever a URL, defined by a certain patern, is loaded. In our case
 
       we load both js and css whenever an iGEM edit page is loaded. The javascipt that is loaded
 
       we load both js and css whenever an iGEM edit page is loaded. The javascipt that is loaded
Line 467: Line 464:
 
       to then load the script file is that it allows for a cleaner separation of files as well as a faster loading solution
 
       to then load the script file is that it allows for a cleaner separation of files as well as a faster loading solution
 
       when the scipt is large.</p>
 
       when the scipt is large.</p>
      <p>The script.js file contains the source code and several add-on pieces of code from a js library called CodeMirror.
+
    <p>The script.js file contains the source code and several add-on pieces of code from a js library called CodeMirror.
 
       This provides the majority of functions that alter the page. It also contains the final function that runs when the  
 
       This provides the majority of functions that alter the page. It also contains the final function that runs when the  
 
       Document OnLoad call is made. This final function finds the textarea tag by its ID and makes the call to CodeMirror
 
       Document OnLoad call is made. This final function finds the textarea tag by its ID and makes the call to CodeMirror
Line 473: Line 470:
 
       and applies the css. As well as defining and instigating a few other features, this performs the majority of the  
 
       and applies the css. As well as defining and instigating a few other features, this performs the majority of the  
 
       work</p>
 
       work</p>
      <p>By packing the majority of the js into one file it reduces the overall space required and time neaded to load.
+
    <p>By packing the majority of the js into one file it reduces the overall space required and time neaded to load.
 
       That being said it is well commented and laid out so that it is easily editable in the future. The same runs
 
       That being said it is well commented and laid out so that it is easily editable in the future. The same runs
 
       true for the css.</p>
 
       true for the css.</p>
     
+
 
      <h3>Future Work</h3>
+
    <h3>Future Work</h3>
      <p>There are several features we would like to implement in the future to make this the best tool, and the only
+
    <p>There are several features we would like to implement in the future to make this the best tool, and the only
 
       as far as we know, for editing the iGEM wiki. Javascipt, CSS, and HTML are all currently supported but providing  
 
       as far as we know, for editing the iGEM wiki. Javascipt, CSS, and HTML are all currently supported but providing  
 
       syntax for SCSS and other CSS variants, as well as PHP would complete the language mark up types. Providing  
 
       syntax for SCSS and other CSS variants, as well as PHP would complete the language mark up types. Providing  
 
       code suggestion as well as auto complete would make this a tool to rival the best code editors out there.</p>
 
       code suggestion as well as auto complete would make this a tool to rival the best code editors out there.</p>
      <p>Another project we have begun work on is developing a larger tool coaltes our tool with other team's
+
    <p>Another project we have begun work on is developing a larger tool coaltes our tool with other team's
 
       to create a complete IDE for developing iGEM wikis.</p>
 
       to create a complete IDE for developing iGEM wikis.</p>
      <p>This tool will and can make a massive difference to teams current and futrue by making the process of creating  
+
    <p>This tool will and can make a massive difference to teams current and futrue by making the process of creating  
 
       a wiki infinitely more easy and enjoyable to do!</p>
 
       a wiki infinitely more easy and enjoyable to do!</p>
 
+
 
 
+
 
 
+
 
 
   <h2>Mind-the-Growth</h2>
 
   <h2>Mind-the-Growth</h2>
 
   <img src="https://static.igem.org/mediawiki/2015/5/5c/Mind_the_Growth_icon.png"/>
 
   <img src="https://static.igem.org/mediawiki/2015/5/5c/Mind_the_Growth_icon.png"/>

Revision as of 16:52, 10 September 2015

'



Software

We have developed two incredible tools to help not only our project but all of iGEM!

Mind-the-Mark




Summary

The Mind-the-Mark tool takes the bland and boring wiki input box and transforms it into a proper code editor with several interactive and assistive features. Having talked to several iGEM teams this year, and years past, one of the issues they lamented over was the issue of entering code into the wiki. The bland and simple text input on each page made developing interactive and pretty wikis a real hassle. Due to this many teams developed their code externally and then transfered it in, costing them time and effort. We have changed that.

Before
After

By taking advantage of Google's easy to use extension system for the Chrome Browser, we devised a powerful and lightweight extension that transforms the wiki editor on whatever page you choose to edit; be it in the future in 2020 or now in 2015. The extension is easily downloaded and then drag-and-dropped into the Chrome browser, to install. Then its working!

Download the Tool!
GitHub
Chrome Store

Construction

The spirit of the tool is to make editing and working on the iGEM wiki easier and more interactive for all. It was with this spirit that we built the tool. Although the code is part of chrome extension, it is really a lightweight javascript tool.

What is a Chrome Extension?

A chrome extension at its base is a .json file called the "Manifest" file that contains the file reference's and basic information about the tool. When used this tells the browser to load a piece of javascript or other files on to specified pages. These then interact with the DOM (Document Object Model) of the page.

Why use a Chrome Extension?

Chrome is one of the most modern and widely used browser on the internet and has an easy to use and develop extension system, on top of a very rich API. When loading files that interact with the DOM chrome extensions also make sure that there is no interaction with any of the loaded scripts of libraries from the page, protecting the user. To top it all off, the chrome extensions are very easy to install and distribute.

How did we Implement it?

Our tool uses the commonly implemented "Content_Scripts" method for loading our extension. This allows chrome to load specific js and css files whenever a URL, defined by a certain patern, is loaded. In our case we load both js and css whenever an iGEM edit page is loaded. The javascipt that is loaded is the background.js file which adds a script refecence to the page, loads the script, and then deletes it. In this instance the script in question is the script.js file. The extension also has the ability to access other js and css file which are referenced in the Manifest file. The reason the background.js file is used to then load the script file is that it allows for a cleaner separation of files as well as a faster loading solution when the scipt is large.

The script.js file contains the source code and several add-on pieces of code from a js library called CodeMirror. This provides the majority of functions that alter the page. It also contains the final function that runs when the Document OnLoad call is made. This final function finds the textarea tag by its ID and makes the call to CodeMirror to change the textarea into the new snazzy code editor. CodeMirror then alters the shape of the divs in the tag and applies the css. As well as defining and instigating a few other features, this performs the majority of the work

By packing the majority of the js into one file it reduces the overall space required and time neaded to load. That being said it is well commented and laid out so that it is easily editable in the future. The same runs true for the css.

Future Work

There are several features we would like to implement in the future to make this the best tool, and the only as far as we know, for editing the iGEM wiki. Javascipt, CSS, and HTML are all currently supported but providing syntax for SCSS and other CSS variants, as well as PHP would complete the language mark up types. Providing code suggestion as well as auto complete would make this a tool to rival the best code editors out there.

Another project we have begun work on is developing a larger tool coaltes our tool with other team's to create a complete IDE for developing iGEM wikis.

This tool will and can make a massive difference to teams current and futrue by making the process of creating a wiki infinitely more easy and enjoyable to do!

Mind-the-Growth

Model based on cellular Automata

Cellular automata are discrete models used across a variety of disciplines. The model consists of a grid of cells that are assigned one of several possible states which can be thought of as the identity of the cell. Each of these possible states has a set of rules which determine if and how the state of the that cell will change as time progresses. The model operates on discrete time, so all the states at t+1 are determined by how the grid looks at time t. The purpose of the creation of this particular model was to determine the optimum way in which a combination of probiotics and prebiotics can be used to change an initial microbiome profile to a pre-determined one. This model is a simplification that offers a framework to which more variables can be added, as well as experimental data. The states 1-6 represent different five different bacterial phyla, with state 6 representing all other phyla. The bacteria were randomly generated on a grid of cells according to a pre-determined proportion using a random number generator. As time progressed the state of each cell on the grid changed according to a set of rules that took into account the following variables: The states of the eight cells that surround it. Durability and strength constants that were defined for each of the phyla A cooperation/competition constant that take into account the proportion of the overall population that belongs to the same phyla A constant to take into account each phylum’s response to the prebiotic (inulin) Each of these factors is set to zero or one in the source code, so as to eliminate its influence on the model. Each user can then set the constants as he or she sees fit. The system is disrupted periodically by the addition of a dose of Prokao containing inulin and bacteria of different phyla, whose values can also be adjusted as needed.

For more information, the source cod go to Our Github Page.

How to Improve this Model

Given the amount of variables involved we would need to incorporate machine learning, such as a genetic algorithm, in order to come up with a composition of Prokao that’s even close to the ideal. Quorum sensing could be incorporated by having particular actions at a distance between cells, and have those effects diminish with the distance between them. More complex functions based on particular limiting nutrients could be used to define the nature of cooperation and competition between different states. The model could be expanded to a 3D space fairly easily. We chose not to do this because of constraints related to the visual rendering and processing power. Experimental data could be interpreted in the context of the model and used to make the simulation more accurate. Current theoretical frameworks could also be incorporated in future versions of this model. More possible states could be represented, in this case going down to the genus or even species level. With overarching characteristics that defining a phyla and particular characteristics to each genus and so on. Non-bacterial actors such as archaea, fungi and parasites could also be considered. The “other” state could be more accurately modelled by having each of it’s cells behave in a different way and thus eliminating any competition or cooperation between them. Empty space can be considered as one of the possible states, thereby making it possible to model initial colonisation. Limiting factors which increase periodically such as carbon sources or specific nutrients which are essential for the growth of particular bacteria. Cellular products could be produced, consumed and accumulated leading to different effects. http://www.sciencedirect.com/science/article/pii/S002251931500003X http://www.sciencedirect.com/science/article/pii/S0022519315000594 http://www.sciencedirect.com/science/article/pii/S0022283614001788 http://journals.plos.org/plosone/article?id=10.1371/journal.pone.0066019 https://en.wikipedia.org/wiki/Lotka%E2%80%93Volterra_equation http://www.sciencedirect.com/science/article/pii/S0889159115001105