Team:UCL/Software
'
Mind-the-Mark
The Tool
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 iGEM 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, or installed with a click from the chrome store. Then its working!
Before |
After |
|
|
Description
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.
Features
- Syntax Markup for HTML, XML, CSS, Javascript
- Customized Layout and Design
- Tag Highlighting and linking
- Line Count
- Ctrl-F for Finding, replacing, and searching with RegExp
- Open Source and Fully Changeable
- Much More!
For a more indepth update history and singular repository see the following link beside the one below
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 future by making the process of creating a wiki infinitely more easy and enjoyable to do!
Mind-the-Growth
The Tool
When we first discussed adding a probiotic bacteria into the human gut one of the questions that come up was what effect would it have on the human’s microbiome. In order to understand and gain some insight into the functioning of the human microbiome we decided to model it!
Many of the current models that model the human microbiome are descriptive, and use mathematical models and other logical operations to create a system that mimics the gut loosely. [Link]Bucci v. and Xavier J. Towards Predictive Models of the Human Gut Microbiome, Journal of Molecular Biology Volume 426, Issue 23, 25 November 2014, Pages 3907–3916 [1] One of the challenges is that although there exist complex models of single cell dynamics, that use operations like mean-field partial differential equations, the computational power needed to expand any discrete models to a population is very high.
A potential solution to this is using metabolic analysis as a descriptive tool for modelling the activity of the populations. What we have done is built a lightweight framework in both C++ and in C# to enable researchers to expand and build upon this concept in the future. Not only does this tool render cell population graphics in a physics engine but it also has been used to examine the effect that consuming probiotics and prebiotics (inulin in this case) has on the gut microbiome.
For a more indepth update history and singular repository see the following link beside the one below
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-5 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.