Home page source code. Source lies in branch source. Github build goes to
master.
-
Install bundle and project dependencies
bundle install -
Add content. See here for details.
-
Collect updates from github repositories mentioned in files.
bundle exec rake collectRunning this uses unauthenticated requests to Github's API. The limit is 60 per hour. Recommended way is to generate a personal token (https://github.com/settings/tokens) and run collect command as
env GH_TOKEN='<token-here>' bundle exec rake collect -
Serve/build with jekyll
bundle exec jekyll serve bundle exec jekyll build
The website uses jekyll and most of the pages get their content directly using
the markdown/html template, except a few pages for which the data source is a
kept in separate files and then is injected to the template via plugins kept in
_plugins.
- Team members data go in
_data/team.yml - Publications go in
_data/publications.yml - New sections for 'research' and 'teaching' page go in
_researchand_teachingdirectory respectively.
Pull requests should go to source branch (not master) since travis builds the
website from there.
A short description of the data files follow:
This contains publications that get displayed on the /publications page. A full featured entry for a publication looks something like the following:
title: Title of the publication
doi: >
[Optional] doi like 10.1371/journal.pone.0035564. This adds the links for
'Open doi link' and 'Save to mendeley'.
slug: >
Unique identifier which also maps to a pdf in ./pdfs/publications/<slug>.pdf
(in case a pdf link is not provided) and an image in
./images/publications/<slug>.png
journal: [Optional] Journal name
year: year
volume: [Optional] volume
pages: [Optional] pages
authors: Name of authors (this should be a yaml list but is just a string right now)
keywords: >
[Optional] Comma separated keywords (this also should be a list but is string
as of now)
abstract: Abstract
preprint: [Optional] Link to a preprint
pdf: >
[Optional] Link to pdf. This takes priority over
./pdfs/publications/<slug>.pdf
github: [Optional] Github repository identifier like <user>/<repo>This contains information about lab members. An entry looks like this:
name: Member name
role: Role
description: Blurb
image: >
A full url to an image (like https://example.com/image.png) or path to local
image file (like /images/people/foo.png)
# Links is a list of links the member wants to show under his/her description
# In case of no links, put '[]' (empty list) here.
links:
- name: Link name
url: Url
- name: Link 2
url: Url
type: >
[Optional] The type of member. This is different than role and is used to
categorize list of members in sections like 'Alumni'.Both the research and
teaching page are organized in terms of sections
or themes which map to a set of markdown files in the directories _research
and _teaching respectively. Each files contains metadata in its yaml front
matter and the section's summary as its main text. Here is an example markdown
file:
---
title: Section title text
image: /images/research/foo.png # The image for the section
# A list of projects which can either be a github identifier or a dictionary
# with title and description keys
projects:
- user/repo
- group/repo
- title: Project title
description: Project description
publications: >
[Optional] Comma separated keywords mapping to that of _data/publications.yml
---
Here goes the section summary.Overall, the source code follows the usual jekyll
structure. We use a few additional custom scripts/plugins to work with data
files like _data/team.yml. This section documents the peripheral tooling
involved.
Plugins in ./_plugins read in the data from ./_data, ./_research and
./_teaching and provide them as variables in the corresponding pages (like
./teaching.html for _teaching).
Since the plugin and html file for research and teaching look very similar, we
generate both of them from a single source file using
ribosome. We call these pages (research
and teaching) thematic pages. The ruby plugin file is generated from
./_scripts/theme-gen-gen.rb.dna and the html file from
./_scripts/theme-page.html.dna. The process is scripted in the rakefile and is
described in the next section.
We use rake for specifying and running tasks..
The main tasks are collect and build.
Before building the website, we need to collect some metadata (last commit
information etc.) about github repositories listed in the files
./_research/*.md and ./_teaching/*.md. This involves using the github api
and running the script ./_scripts/collect-repos.rb. The following command runs
this task and produces an updated ._data/repositories.yml file with all the
metadata required:
bundle exec rake collectSince github api has limits, we need to pass a token so that the task can finish successfully:
env GH_TOKEN='<token-here>' bundle exec rake collectThis is the main build task which just wraps around jekyll's own build.
bundle exec rake buildThis task generates a thematic page template (the html file). It needs two extra arguments,
- The name of the theme page (like 'research' or 'teaching')
- Short text (divider text) which goes over the list of projects (like 'LINKS' in teaching and 'PROJECTS' in research)
The command below will produce a page ./teaching.html with a divider text
'ITEMS'.
bundle exec rake tpen[teaching,items]This produces a ruby plugin for corresponding (html of the same name) thematic page. It needs one extra argument which is the name of the theme page.
The command below produces a plugin ./_plugins/teaching.rb and works with the
template page ./teaching.html using data from _/teaching directory.
bundle exec rake ggen[teaching]We use travis to run the website build process every time commits are pushed on github. Travis also rebuilds the website each night so that the information collected about the github repositories stays fresh.
The main file for travis is ./build.sh which checks for a few things (like
which branch are we building for) and runs the rake tasks collect and build.
Once done, it pushes the generated static html files to the repository's master
branch. For pushing, it needs an authentication key which is kept encrypted in
the file ./deploy_key.enc.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent