Difference between revisions of "Team:UCL/Software"

Mind-the-Mark

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

Construction

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.

Future Work

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. 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.