YEAST-AID

Software

The source codes are shown in the GitHub repository within the igemsoftware2021 github page.

Hexogem

We developed our original deployment system for iGEM Wiki, called Hexogem.

Hexogem is an efficient and iGEM-server-friendly wiki development system. It consists of some plugins for Hexo and the revised version of iGEM-WikiSync, which was developed by iGEM BITS Goa in 2020.

What is Hexo?

Before the explanation of Hexogem, we will describe what is Hexo.
Hexo is one of the famous static site generator(SSG)s. It allows us to write posts in Markdown format, choose cool themes and generate a site in one command hexo generate. There are some similar frameworks like Hexo, some of which you may know: Nuxt.js, Gatsby, Hugo, Pelican, and so on.

Using MediaWiki Templates for partial embedding

If you use general SSGs, common components such as navigation bar or footer are directly embedded to each page. Thus, if you modify the content of the footer just a bit, for example, you have to upload all pages again. This is a very troublesome situation. Even if you solve the trouble by using an automated upload system like iGEM-WikiSync developed by iGEM BITS Goa, the iGEM server still gets many rewrite requests, which may slow the iGEM server’s responses.

In contrast, Hexogem is a very iGEM server-friendly system. It does not embed common components to each page directly. Instead, it uses MediaWiki Templates. For example, if you want to add a footer to each page, Hexogem does not embed its HTML code, but embeds {{ Template:SomeTeam/Footer }} to the pages. Thus, it avoids repeating the same code in all pages. If you change the content of the footer, all you have to do is update the template of the footer.

Now, we are updating this section in a very slowed iGEM server. We felt Hexogem is needed. Among the requests which make iGEM server slow might be a tiny design update of menubar or modification of the content in footer. These are redundant requests due to updating the content of common components among many pages. They will be reduced by using MediaWiki Templates. Hexogem allows us to use MediaWiki Templates even when we develop our wiki locally and use some synchronizing systems.

We have developed this by rewriting Hexo’s internal function. In fact, Hexo’s themes internally use _partial() in order to embed common components. Thus, we have changed this function to export MediaWiki Template Code when exporting to iGEM Wiki. For example, if the theme in Hexo internally calls _partial('something') in order to embed some common component, the rewritten _partial() function returns the text {{ Template:TeamName/template/something }}. Moreover, the system records what component is referenced in _partial() function and exports each recorded component to a template file.

Deploying the site automatically with the power of iGEM-WikiSync

iGEM-WikiSync’s ability is fantastic. It can upload files by launching a virtual browser inside the system. Moreover, it makes “upload map” in the folder and manages which files have been changed since the last upload. These features are very useful in developing iGEM Wikis. By using and partially modifying iGEM-WikiSync, we developed the automated uploading system of Hexo-generated sites.

The original version of iGEM-WikiSync does not support MediaWiki Templates, so we have developed this point. When html files are provided in template/ folder in src_dir, they are uploaded to the directory under Template:Team Name/template/, not to Team:Team Name/. Thus, those files can be called in {{ Template:Team Name/template/some-file }} from the Wiki pages. In order to achieve this, we modified the iGEM-WikiSync system to replace the URL in the upload map if the file is under template/ folder.

Moreover, we have fixed the internal HTML processing system in iGEM-WikiSync. iGEM-WikiSync seems to use the HTML processing system in order to replace URL paths of assets. The URL replacing system is one of the great features of iGEM-WikiSync, but the internal HTML processing system does not interpret HTML files with MediaWiki syntax correctly. We have to write MediaWiki syntax outside <html> element, so if we want to embed MediaWiki Templates in a  element, for example, we have to write </html>{{ SomeTemplate }}<html>. HTML structure is broken in this expression, so we dealt with this problem in the following way.

Outputs MediaWiki Syntax without </html> and <html>. In the example above, {{ SomeTemplate }}
Passes over the output to the internal HTML parser in iGEM-WikiSync.
Replaces {{ with </html>{{, and }} with }}<html>.
Then, the correct expression for iGEM Wiki is generated. In the example above, </html>{{ SomeTemplate }}<html>.

Continuous Integrations on GitHub Actions

As well as the original iGEM-WikiSync, Hexogem supports CI on GitHub Actions.

By using CI, we can automatically generate and deploy the wiki. You don’t have to run the generating command or upload the files and assets one by one.

The workflow file should be consist of the parts below:

Generating the site from Hexo format to iGEM Wiki format, by running the command hexo generate --wiki
Sync the site by calling the revised version of iGEM-WikiSync.
Since WikiSync updates upload_map.yml, you have to commit this change and push in the workflow.

Hexo command uses Node.js and WikiSync uses python. Thus you need to setup both Node.js and python in your workflow.

A workflow example is shown in the GitHub repository of the judging release.

Providing the similar environment to iGEM server for local testing

Sites which use Hexo are easily tested locally by the command hexo server. However, the environment of iGEM server is very complex and far from the local testing environment. Thus, we have simulated the iGEM server environment locally.

If we call hexo server command with the argument of --wiki, codes used in iGEM server are inserted to the <head> and <body> tag.

We have achieved this by using Hexo Injector, a Hexo's feature for developing plugins.

Hexogem will help many teams who want to use site generators for developing wiki

In recent years, many iGEM teams seem to use some generating system, such as Nuxt.js or other static site generators, rather than directly editing and writing their wiki. Though this system only targets Hexo currently, the three essential features shown above are useful for many teams who use some generating system for developing wiki.
Since the implementation of the three features requires the modification of those systems or creating some plugins specific for the systems, these features have to be implemented to each system as necessary in the future.

Other softwares

We implemented other softwares for efficient wiki development.

These are the plugins of Hexo. Hexo is a very expandable system and there are many plugins created by users.

hexo-plugin-attribution-table

This plugin generates our attribution table in the Attributions page. In the post file of the Attributions page, the table is written in the following format:

{% attribution %}
{
  "columns": ["Wet Lab", "Modelling", "Hardware", "Human Practices", "Wiki", "Videos", "Marketing", "Collaboration", "Member Recruitment"],
  "members": {
    "Rintaro Shimojo": ["Wet Lab", "Modelling", "Human Practices", "Wiki", "Videos", "Marketing", "Collaboration", "Member Recruitment"],
    "Kiyoshi Ishida": ["Wet Lab", "Videos"],
    "Shun Ono": ["Wet Lab", "Modelling", "Hardware", "Human Practices", "Collaboration", "Member Recruitment"],
    "Maki Kato": ["Wet Lab", "Collaboration", "Member Recruitment"],
    "Ryoichi Hirashima": [ "Marketing" ],
    "Ayumu Hyodo": ["Wet Lab", "Modelling", "Human Practices", "Collaboration", "Member Recruitment"],
    "Soya Ito": ["Wet Lab", "Videos"],
    "Ichii Shirasuna": ["Modelling", "Marketing"],
    "Rintaro Niimi": ["Modelling", "Wiki"],
    "Hana Obata": ["Wet Lab", "Wiki"],
    "Shun Katsumi": ["Modelling", "Wiki"],
    "Asako Kitai": ["Wet Lab", "Human Practices", "Videos"],
    "Mahiro Suematsu": ["Wet Lab", "Videos"],
    "Keita Hoshino": ["Wet Lab", "Human Practices", "Marketing"],
    "Rurika Motohashi": ["Modelling", "Hardware", "Human Practices"],
    "Ryo Suda": ["Modeling", "Wiki", "Videos", "Marketing"],
    "Kensei Okada": ["Wiki", "Videos", "Marketing", "Member Recruitment"]
  }
}
{% endattribution %}

This plugin reads the text between {% attribution %} and {% endattribution %} tag, and converts it to html <table> format.
This prevents the redundant writing of ● in our table and allows us to write the table in structured format. This plugin is useful not only for the attribution table in iGEM but also some tables using ●.

An example is shown in the GitHub repository of the judging release.

hexo-plugin-gallery

This plugin generates the gallery similar to our Team page. In the post file of the page, the table is written in the following format:

{% memberssimple %}
[
  {
    "caption": "Yuichi Wakamoto",
    "description": "Associate Professor in Department of Basic Science, Graduate School of Arts and Science"
  },
  {
    "caption": "James Ellinger",
    "description": "Assistant Professor in Center for Global Communication Strategies"
  }
]
{% endmemberssimple %}

For developing a plugin, we generalized the expression, and the gallery format is a little different from the code above. (For example, we changed the tag name from memberssimple to gallery.)

An example is shown in the GitHub repository of the judging release.

This plugin reads the text between {% gallery %} and {% endgallery %} tag, and converts it to html format.

This plugin shows images, captions, and descriptions in the gallery format.

We added further implementations for our team members gallery (eg. showing favorite sushi and biological terms), but these features are so specific to our use that they are excluded from the plugin release.

This plugin can be used for Hexo-generated sites which use some galleries.

Team:UTokyo/Software