diff --git a/.gitattributes b/.gitattributes new file mode 100644 index 0000000..1fecb68 --- /dev/null +++ b/.gitattributes @@ -0,0 +1,5 @@ +############################################################################### +# Set default behavior to automatically normalize line endings. +############################################################################### +* text=auto + diff --git a/.github/workflows/pages.yml b/.github/workflows/pages.yml new file mode 100644 index 0000000..3da6c24 --- /dev/null +++ b/.github/workflows/pages.yml @@ -0,0 +1,56 @@ +# Build the Jekyll site (github-pages gem) and deploy it to GitHub Pages. +# Ported from the original GitLab CI (`bundle exec jekyll build`). Pull requests +# build the site to validate it; only pushes to main deploy. +name: Deploy Jekyll site to Pages + +on: + push: + branches: ["main"] + pull_request: + workflow_dispatch: + +permissions: + contents: read + pages: write + id-token: write + +# Allow one concurrent deployment; do not cancel an in-progress production run. +concurrency: + group: "pages" + cancel-in-progress: false + +jobs: + build: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@v4 + + - name: Setup Ruby + uses: ruby/setup-ruby@v1 + with: + ruby-version: "3.1" + bundler-cache: true + + - name: Build with Jekyll + run: bundle exec jekyll build + env: + JEKYLL_ENV: production + + - name: Upload artifact + uses: actions/upload-pages-artifact@v3 + with: + path: _site + + deploy: + # Build validates on PRs; deploy only from main / manual dispatch. + if: github.event_name != 'pull_request' + needs: build + runs-on: ubuntu-latest + environment: + name: github-pages + url: ${{ steps.deployment.outputs.page_url }} + steps: + - name: Deploy to GitHub Pages + id: deployment + uses: actions/deploy-pages@v4 diff --git a/00_principles.md b/00_principles.md new file mode 100644 index 0000000..a617f34 --- /dev/null +++ b/00_principles.md @@ -0,0 +1,25 @@ +--- +layout: page +title: Principles +permalink: /principles/ +--- +# Focus Topics + +The *Principles* course covers five focuses in five days. Those Focuses are: + + - Project Planning & Design + - Workspace Organization & Tools + - Reuse & Reusability + - IO, Big and small + - High Performance Computing + +# Schedule + +Each day adopts a different lens on **your work**, and follows the same schedule: + + - warming up, + - opening with a faculty-led *focus discussion* on core concepts, + - transitioning to a *applied practical* where participants work a structured problem, and + - culminating in *project work* devoted to tasks and feedback on **your project**. + +The mornings start with [Warmups]({{ '/warmup/' | relative_url }}) followed by the [Focus Topics]({{ '/topic/' | relative_url }}), where the faculty engage participants in the important ideas & practices in the day's topic; these sessions are very interactive, and include several partnered mini-exercises. In the afternoon, we shift to working more with the keyboard. First, we complete a [Practical]({{ '/practical/' | relative_url }}) example problem tailored to the day's topic. Lastly, the participants close out each day working through a series of [project tasks]({{ '/project/' | relative_url }}) applied to *their own projects*; the faculty prepare these challenge lists to exceed what can be accomplished in the available time, so participants will be able to choose what aspects of their work they want pursue in greater depth. \ No newline at end of file diff --git a/01_workshop.md b/01_workshop.md new file mode 100644 index 0000000..a7d30d4 --- /dev/null +++ b/01_workshop.md @@ -0,0 +1,8 @@ +--- +layout: page +title: Workshop +permalink: /workshop/ +--- +Our *SEAMS Workshop* extends the [Principles]({{ '/principles/' | relative_url }}) course to include a hack-a-thon during the second week. The topic focus and schedule for the first week remains largely the same, though we integrate development of a work plan for the hack-a-thon. + +During the hack-a-thon week, the schedule is more flexible. Participants meet with faculty on a regularly scheduled basis to check-in on how their plan is progressing, but *they set that plan*. The workshop wraps with participants demonstrating changes to their project's engineering. diff --git a/02_schedule.md b/02_schedule.md new file mode 100644 index 0000000..b9ff6bd --- /dev/null +++ b/02_schedule.md @@ -0,0 +1,39 @@ +--- +layout: page +title: Schedule +permalink: /schedule/ +--- + +{:.schedule-table} +| Design | Workspace | Reuse | IO | HPC | +|:------------------------------:|:---------------------------------:|:-----------------------------:|:--------------------------:|:---------------------------:| +| [Discussion]({{ '/session/design' | relative_url }}) | [Discussion]({{ '/session/workspace' | relative_url }}) | [Discussion]({{ '/session/reuse' | relative_url }}) | [Discussion]({{ '/session/io' | relative_url }}) | [Discussion]({{ '/session/hpc' | relative_url }}) | +| [Practical]({{ '/practical/design' | relative_url }}) | [Practical]({{ '/practical/workspace' | relative_url }}) | [Practical]({{ '/practical/reuse' | relative_url }}) | [Practical]({{ '/practical/io' | relative_url }}) | [Practical]({{ '/practical/hpc' | relative_url }}) | +| [Project]({{ '/project/design' | relative_url }}) | [Project]({{ '/project/workspace' | relative_url }}) | [Project]({{ '/project/reuse' | relative_url }}) | [Project]({{ '/project/io' | relative_url }}) | [Project]({{ '/project/hpc' | relative_url }}) | +| [Reference]({{ '/topic/design' | relative_url }}) | [Reference]({{ '/topic/workspace' | relative_url }}) | [Reference]({{ '/topic/reuse' | relative_url }}) | [Reference]({{ '/topic/io' | relative_url }}) | [Reference]({{ '/topic/hpc' | relative_url }}) | + +The schedule for SEAMS is divided into two weeks; only the first week applies for the *Principles* course. + +Week 1 concerns our five topic focuses (more below), with each day comprising: + - Warmup, roughly 0830-0930: a quick exercise to get participants thinking + - Topic Discussion, roughly 0930-1230 with a half hour tea break: interactive discussion of the day's focus. + - Lunch, 1230-1330 + - Practical, 1330-1500: a guided practical exercise for the day's topic + - Afternoon tea, 1500-1530 + - Personal Project Work, 1530-1730: participants apply the set of questions from the day's topic to their personal projects + +Optional Weekend group activity: Table Mountain Hike, Saturday morning, approximately 9 AM start (to avoid heat) from Kirstenbosch side. + +Week 2 concerns coached personal project work. At the end of week 1, participants will develop a plan for week 2. + - Monday-Thursday: schedule on an individual basis. Every day will have a scheduled chat with one of the faculty (rotating among them) in the morning and afternoon. + - Friday morning: participants will present their project work to the group + +## Topic Focuses + +We focus on five topic areas: + + - Project Organization: What is required to accomplish your project? What are the pieces that you'll use? How should you arrange them? How will they work together? How can those choices help (or hinder!) you plan to get work done? + - Workspace Tools: What tools should you use? Are there some you have to use? How do they help you work with collaborators? Do they demand too much for those collaborators? Do they comply with your project requirements, like data privacy? + - Reuse & Reusability: Are there parts of your project that someone else (maybe even your past self!) has already implemented? Are there parts that someone else (hopefully, future you!) will want to use? What should you do to make your code more friendly to including other work, and being included elsewhere? + - Input & Output: What kind of data do you have? How much do you have? What format should you support reading in? Storing output in? What lines in your code currently should be input instead? + - High Performance Computing: Where is your project stumbling? Too much data, inefficient implementations? If everything is highly tuned, and it's still too much for your personal machine, what next? How you can break up your problem in bits that will work in parallel? How you can write code that will be cluster-computation ready? diff --git a/99_communications.md b/99_communications.md new file mode 100644 index 0000000..1a8219a --- /dev/null +++ b/99_communications.md @@ -0,0 +1,19 @@ +--- +layout: page +title: Contact Us! +permalink: /communications/ +--- + +Email us at: [seams@aims.ac.za](mailto:{{ site.email }}), or contact us via {% include icon-twitter.html username=site.twitter_username -%}! + +The repository for the course materials is {% include icon-gitlab.html username=site.gitlab_username -%}, where we happily accept accept issues. For updating personal information, we expect workshop alums will also include a pull request. For problems with the site, just a thorough description of the error is enough. + +## Publications + +Past participants: have a publication you want us to recognize (particularly those derived from project work at SEAMS)? Just let us know via [email](mailto:seams@aims.ac.za) or [@SeamsWorkshop](https://twitter.com/SeamsWorkshop)! We will add to the site, distribute to other alumni, *et cetera*. + +## Acknowledgement Statement + +If you think that one of your future publications was substantially influenced by your participation in the SEAMS Workshop, we would appreciate you acknowledging the workshop. We suggest working from the following phrasing, with additional specifics as appropriate: + +> We thank the Software Engineering for Applied Mathematical Sciences (SEAMS) Workshop (link or citation as appropriate) participants and faculty, YEAR and LOCATION, for valuable feedback on early versions of the code underlying this work. In particular, (...description of the major software engineering insights and how they improved the product). \ No newline at end of file diff --git a/Gemfile b/Gemfile new file mode 100644 index 0000000..3d0c654 --- /dev/null +++ b/Gemfile @@ -0,0 +1,15 @@ +source "https://rubygems.org" + +# This will help ensure the proper Jekyll version is running. +# gem "jekyll", "~> 4.3.3" + +gem "github-pages", '~> 232' #, group: :jekyll_plugins + +# Windows does not include zoneinfo files, so bundle the tzinfo-data gem +install_if -> { RUBY_PLATFORM =~ %r!mingw|mswin|java! } do + gem "tzinfo", "~> 1.2" + gem "tzinfo-data" +end + +# Performance-booster for watching directories on Windows +gem "wdm", "~> 0.1.1", :install_if => Gem.win_platform? diff --git a/Makefile b/Makefile new file mode 100644 index 0000000..b8ddd6d --- /dev/null +++ b/Makefile @@ -0,0 +1,83 @@ +## some convenience methods + +run: + bundle exec jekyll serve -w --config=_config.yml,_locconfig.yml + +PROFB ?= master + +profile: + git remote add $(TAR) git@gitlab.com:$(TAR)/seams-workshop.gitlab.io + git fetch $(TAR) + git checkout -b $(TAR)/$(PROFB) + +MOVES = $(wildcard _participants/*.md) + +moves2018: $(subst .md,.yml,$(subst _participants,_data/dec2018,$(MOVES))) + +_data/dec2018/%.yml: + git mv _participants/$*.md $@ || mv _participants/$*.md $@ + +Vertical_Signature_Blue.eps: + rm -f $@ + curl -o temp.zip "http://identity.ufl.edu/wp-content/uploads/2015/11/Vertical_Signature_Blue.eps_.zip" + unzip temp.zip + rm temp.zip + +%.pdf: %.eps + epstopdf $^ + +_includes/logo-UF.svg: Vertical_Signature_Blue.pdf + pdf2svg $^ $@ + +## TODO make target for favicon generation +## found via https://stackoverflow.com/questions/48956465/favicon-standard-2018-svg-ico-png-and-dimensions +## This site seems to do the works, web service API: https://realfavicongenerator.net/api/non_interactive_api#.W1CMltgzbOQ +## looks like need to send SVG + a config.json via POST to site +## then put the results in the right places locally + +RFG := https://realfavicongenerator.net/api/favicon +RFGKEYPATH := ~/Google\ Drive/SEAMS/rfgkey.mk +## TO USE THIS TARGET, MUST DEFINE THIS MAKEFILE LOCALLY, WITH RFGKEY := ... IN IT +-include $(RFGKEYPATH) + +myrfg.json: rfg.json + ## TODO stop unless RFGKEY is something? + sed -e 's/REPLACEME/$(RFGKEY)/g' $^ > $@ + +favicons.zip: myrfg.json + curl -H "Content-Type: application/json" --data @$^ $(RFG) > tmp.json + grep -Eo '"package_url":.*?[^\\]",' tmp.json | sed -e 's/"package_url": "//' | sed -e 's/",//' | sed -e 's/\\//g' > tmp.url + cat tmp.url | xargs curl -o $@ -O + rm tmp.json + rm tmp.url + +_includes/html_code.html: favicons.zip + unzip $^ + mv $(subst _includes/,,$@) $@ + +.PHONY: gbranches + +define brancher +git checkout -B $1-$2 +git push --set-upstream origin $1-$2 + +endef + +gbranches: + $(foreach sess,reference practical project discussion,$(foreach top,design workspace reuse io hpc,$(call brancher,$(sess),$(top)))) + +PROJECTAPIURL = https://gitlab.com/api/v4/projects/7337508 + +define mrequestor # usage $(call mrequestor,$sess-$top,...) +COUNTBRANCHES=`curl --silent "${PROJECTAPIURL}/merge_requests?state=opened" --header "PRIVATE-TOKEN:${gitlabapi}" | grep -o "\"source_branch\":\"$1\"" | wc -l`; if [ $$COUNTBRANCHES -eq "0" ]; then \ + cp mergerequest.json $1.tmp; \ + sed -e 's/REPLACEME/$1/g' $1.tmp > $1.json; \ + rm $1.tmp; \ + curl -X POST "${PROJECTAPIURL}/merge_requests" --header "PRIVATE-TOKEN:${gitlabapi}" --header "Content-Type: application/json" --data @$1.json; \ +fi +# create the correct merge request json + +endef + +gmrs: + $(foreach sess,reference practical project discussion,$(foreach top,design workspace reuse io hpc,$(call mrequestor,$(sess)-$(top)))) diff --git a/README.md b/README.md new file mode 100644 index 0000000..0daf70d --- /dev/null +++ b/README.md @@ -0,0 +1,91 @@ +# SEAMS + +Site for the **Software Engineering for Applied Mathematical Sciences (SEAMS)** +workshop, an ICI3D clinic. Jekyll site (built with the `github-pages` gem), +deployed to GitHub Pages at . + +Migrated from GitLab (`gitlab.com/SEAMS-Workshop/seams-workshop.gitlab.io`) into +ICI3D; see ICI3D/SEAMS#1. Theme and schedule-workflow integration are tracked +against ICI3D/ICI3D.github.io#56 / #54. + +## Using Jekyll locally + +From the repository root: + +1. [Install Jekyll](https://jekyllrb.com/docs/installation/). +1. Download dependencies: `bundle install` +1. Build and preview: `bundle exec jekyll serve` +1. Open . + +## Deployment + +`.github/workflows/pages.yml` builds the site on every push and pull request; +pushes to `main` also deploy it to . Pull +requests build only, to validate. + +The base path is set in `_config.yml` (`baseurl: /SEAMS`), and internal links use +the `relative_url` filter, so a future custom domain serving the site at the root +just needs `baseurl: ""`. + +## Editing + +Work in small chunks, one topic at a time: branch (or fork) the repo, make the +edit, open a pull request, and a maintainer reviews and merges. You can edit +directly in GitHub's web editor (press `.` in the repository, or use the edit +pencil on any file) and open the PR from there. + +# Content Organization + +The SEAMS site content is organized into several `jekyll` collections: + + - warmups (`_warmup`): mental calisthenics. As the name suggests, the warmup exercises for each day. short puzzles. code katas. etc + - topics (`_topic`): brief outline of a concept + reference links. for use outside of discussion session + - sessions (`_session`): material for discussion sessions -- anything people need to download, stuff to display, questions, etc + - practicals (`_practical`): toy problems to focus on particular topics - paired with the discussions to help participants focus on the particular SE concept we discussed, and prep them to apply that thinking to their project + - project (`_project`): guided work for participants particular projects + +To learn more about collections, [see this](https://jekyllrb.com/docs/collections/). The gist of our use, however, is + +# More Details on the Blocks of Content for the Course. + + - Reference Material (`_topics`): + * meant to be read-ahead and take-away + * develop a reference list / reading material / etc page + - Sessions / Discussion (`_session`): + * provide the rough pitch why the participants should care about this topic / perspective, and how they should think about it + * visit ~10 high level concepts within that topic, and how they work together (& with other topics) + * plan opportunities for interactive learning on these concepts: some mini task (~1-3 minutes) in pairs, or full cohort Q&A (~5 minutes), etc + - Practical (`_practical`): + * have an on-computer exercise, working with a toy problem + * should build in complexity; at least 3 levels that everyone will do, with a few more for people that really get it + * should NOT entail a lot of keystrokes to do right; the practical time should mostly be people struggling with new concepts / approach, not rapid-fire typing + * will need to prep code and input in addition to directions + - Project: + * provide a list of questions / tasks to give to participants to apply to their own work + * these questions should also suggest how the results can be incorporated into project + * also need a rubric / guidance / etc for other faculty to evaluate against to help them provide feedback to participants + +# Some Example / Reference for Blocks of Content + +Project Planning & Design Session, ~10 concepts might include: + 1. Requirements + 2. Separation of Concerns / Design Patterns + 3. DRY vs KISS vs Too-Much-Magic + 4. Testing - validation vs verification vs performance (overlap w/ workspace org - having testing infrastructure), + 5. process / work flow maps & pseudo code => real code + 6. documentation (overlap w/ workspace org) + 7. distribution (overlap with reuse & reuseability) + 8. general coding best practices (conventions), etc... + +mini exercises: code "telephone" + +Project planning & design practical: toy problem to do with morse code. tasks: figure out work flows for parse, then de-parse, then identify overlap, then propose useful separate of pieces (e.g., reference non-code file for translation map, input / output separate from core dot-dash to alphanumeric and vice versa + +Project planning & design applied to their project, example tasks: +- draw the flow diagram for each of the pieces your research work associated with this project, including inputs, outputs +- across those flows for each part, identify the "conserved" pieces +- list the requirements for your project: what kind of inputs must be used? what sort of outputs? what analysis rules must be met? +- what are possible intermediate products in your work? what are the dependency relationships between those pieces? +- what part of your project is specific? what part is generic to similar problems? +- what is the 1 sentence description of your project? ...the 1 paragraph? ...the 1 page? +- who is the audience / customer for this work? how will they use the work? what context do they work in? diff --git a/_config.yml b/_config.yml new file mode 100644 index 0000000..546a640 --- /dev/null +++ b/_config.yml @@ -0,0 +1,84 @@ +# Welcome to Jekyll! +# +# This config file is meant for settings that affect your whole blog, values +# which you are expected to set up once and rarely need to edit after that. +# For technical reasons, this file is *NOT* reloaded automatically when you use +# 'jekyll serve'. If you change this file, please restart the server process. + +# Site settings +title: SEAMS Workshop +longtitle: SEAMS Workshop v7 ~ 17-28 Feb 2025! +nextdate: 17-28 Feb 2025 +email: carl.ab.pearson@gmail.com +description: > # this means to ignore newlines until "baseurl:" + The Software Engineering for Applied Mathematical Sciences (SEAMS) Workshop site, + covering logistics and materials. +baseurl: "/SEAMS" # GitHub project-site path (ici3d.github.io/SEAMS); set to "" if a custom domain serves it at root +url: "https://ici3d.github.io" # the base hostname & protocol for your site +twitter_username: SeamsWorkshop +gitlab_username: SEAMS-Workshop + +# Build settings +markdown: kramdown +exclude: ["README.md", "Makefile", "*.json", "*.mk", "_faculty/template.md", "_participants/template.md", "*.sh"] + +# taking_apps: +# url: https://forms.gle/3x9c3JoeD2uhNBE87 +# end: '01 January 2023' +# jsdt: "2023-01-01" + +# Collections +collections: + warmup: + output: true + permalink: /:collection/:slug/ + topic: + output: true + permalink: /:collection/:slug/ + session: + output: true + permalink: /:collection/:slug/ + practical: + output: true + permalink: /:collection/:slug/ + project: + output: true + permalink: /:collection/:slug/ + faculty: + output: false + participants: + output: false + + + +defaults: + - + scope: + path: "" + type: warmup + values: + layout: page + - + scope: + path: "" + type: topic + values: + layout: page + - + scope: + path: "" + type: session + values: + layout: page + - + scope: + path: "" + type: practical + values: + layout: page + - + scope: + path: "" + type: project + values: + layout: page diff --git a/_data/dec2018/awe.yml b/_data/dec2018/awe.yml new file mode 100644 index 0000000..fa2cd93 --- /dev/null +++ b/_data/dec2018/awe.yml @@ -0,0 +1,12 @@ +fullname: Olaitan Awe +goby: Olaitan +img: awe.jpg +links: + - + title: LinkedIn + url: https://www.linkedin.com/in/olaitanawe +affiliation: + - + org: University of Ibadan + position: PhD Candidate +status: complete \ No newline at end of file diff --git a/_data/dec2018/bingham.yml b/_data/dec2018/bingham.yml new file mode 100644 index 0000000..91c0c65 --- /dev/null +++ b/_data/dec2018/bingham.yml @@ -0,0 +1,15 @@ +fullname: Jeremy Bingham +goby: Jeremy +img: bingham.jpg +links: + - + title: Masters project repo + url: https://github.com/JemJenn/Risk-Incidence + - + title: Social modelling + url: https://github.com/JemJenn/Own_Social_Models +affiliation: + - + org: '[SACEMA](https://www.sacema.org) - [Stellenbosch University](http://www.sun.ac.za)' + position: Masters Student +status: complete \ No newline at end of file diff --git a/_data/dec2018/bruce.yml b/_data/dec2018/bruce.yml new file mode 100644 index 0000000..75d6e69 --- /dev/null +++ b/_data/dec2018/bruce.yml @@ -0,0 +1,8 @@ +fullname: Faikah Bruce +goby: Faikah +img: bruce.jpg +affiliation: + - + org: '[SACEMA](https://www.sacema.org) - [Stellenbosch University](http://www.sun.ac.za)' + position: PhD Student +status: complete \ No newline at end of file diff --git a/_data/dec2018/burengengwa.yml b/_data/dec2018/burengengwa.yml new file mode 100644 index 0000000..81a1ddc --- /dev/null +++ b/_data/dec2018/burengengwa.yml @@ -0,0 +1,8 @@ +fullname: Gloria Burengengwa +goby: Gloria +img: burengengwa.jpg +affiliation: + - + org: '[Stellenbosch University](http://www.sun.ac.za)' + position: MSc Student +status: complete \ No newline at end of file diff --git a/_data/dec2018/delva.yml b/_data/dec2018/delva.yml new file mode 100644 index 0000000..03ad7bf --- /dev/null +++ b/_data/dec2018/delva.yml @@ -0,0 +1,12 @@ +fullname: Wim Delva +goby: Wim +img: delva.jpg +links: + - + title: Google scholar page + url: http://scholar.google.co.za/citations?user=7tUIcCIAAAAJ&hl=en +affiliation: + - + org: '[SACEMA](https://www.sacema.org) - [Stellenbosch University](http://www.sun.ac.za)' + position: Senior researcher +status: complete \ No newline at end of file diff --git a/_data/dec2018/geza.yml b/_data/dec2018/geza.yml new file mode 100644 index 0000000..768cbcf --- /dev/null +++ b/_data/dec2018/geza.yml @@ -0,0 +1,8 @@ +fullname: Ephifania Geza +goby: Ephie +img: geza.png +affiliation: + - + org: AIMS and University of Cape Town + position: PhD Candidate +status: partial \ No newline at end of file diff --git a/_data/dec2018/kanubala.yml b/_data/dec2018/kanubala.yml new file mode 100644 index 0000000..69c66e0 --- /dev/null +++ b/_data/dec2018/kanubala.yml @@ -0,0 +1,15 @@ +fullname: Deborah Dormah Kanubala +goby: Deborah +img: kanubala.jpeg +links: + - + title: LinkedIn + url: https://www.linkedin.com/in/ddk2018/ + - + title: Mentor + url: https://www.africainternshipacademy.com/mentor/DEBORAH-DORMAH-KANUBALA +affiliation: + - + org: African Institute for Mathematical Sciences, Senegal + position: Masters Student +status: complete \ No newline at end of file diff --git a/_data/dec2018/maher.yml b/_data/dec2018/maher.yml new file mode 100644 index 0000000..2f61394 --- /dev/null +++ b/_data/dec2018/maher.yml @@ -0,0 +1,8 @@ +fullname: Andrew Maher +goby: Andrew +img: maher.jpg +affiliation: + - + org: '[SACEMA](https://www.sacema.org) - [Stellenbosch University](http://www.sun.ac.za)' + position: PhD Candidate +status: complete \ No newline at end of file diff --git a/_data/dec2018/mateyisi.yml b/_data/dec2018/mateyisi.yml new file mode 100644 index 0000000..b59dd36 --- /dev/null +++ b/_data/dec2018/mateyisi.yml @@ -0,0 +1,12 @@ +fullname: Mohau Jacob Mateyisi +goby: Mohau +img: mateyisi.jpg +links: + - + title: LinkedIn + url: https://www.linkedin.com/in/mateyisi +affiliation: + - + org: Council for Scientific and Industrial Research, South Africa + position: Post-doctoral Researcher +status: complete \ No newline at end of file diff --git a/_data/dec2018/mbewe.yml b/_data/dec2018/mbewe.yml new file mode 100644 index 0000000..8957f34 --- /dev/null +++ b/_data/dec2018/mbewe.yml @@ -0,0 +1,12 @@ +fullname: Persverance Mbewe +goby: Percy +img: mbewe.jpg +links: + - + title: LinkedIn + url: https://www.linkedin.com/in/perseverance-nceba-mbewe-114b5393/ +affiliation: + - + org: Council for Scientific and Industrial Research, South Africa + position: Junior Developer +status: partial \ No newline at end of file diff --git a/_data/dec2018/mensah.yml b/_data/dec2018/mensah.yml new file mode 100644 index 0000000..94fe627 --- /dev/null +++ b/_data/dec2018/mensah.yml @@ -0,0 +1,12 @@ +fullname: Samuel Ofosu Mensah +goby: Sam +img: mensah.png +links: + - + title: LinkedIn + url: https://linkedin.com/in/samuelofosumensah +affiliation: + - + org: African Institute for Mathematical Sciences, South Africa + position: Research Masters Student +status: complete diff --git a/_data/dec2018/mhlanga.yml b/_data/dec2018/mhlanga.yml new file mode 100644 index 0000000..e0b35dc --- /dev/null +++ b/_data/dec2018/mhlanga.yml @@ -0,0 +1,8 @@ +fullname: Laurette Mhlanga +goby: Laurette +img: mhlanga.jpg +affiliation: + - + org: '[SACEMA](https://www.sacema.org) - [Stellenbosch University](http://www.sun.ac.za)' + position: PhD Candidate +status: complete \ No newline at end of file diff --git a/_data/dec2018/ndege.yml b/_data/dec2018/ndege.yml new file mode 100644 index 0000000..df4388c --- /dev/null +++ b/_data/dec2018/ndege.yml @@ -0,0 +1,18 @@ +fullname: Benard Charles Ndege +goby: Benard +img: ndege.jpg +links: + - + title: LinkedIn + url: https://www.linkedin.com/in/bcn2018/ + - + title: Data Scientist + url: https://www.ensibuuko.com/ +affiliation: + - + org: Ensibuuko Tech. Limited + position: Data Scientist + - + org: African Institute for Mathematical Sciences, Senegal + position: Msc Student +status: complete \ No newline at end of file diff --git a/_data/dec2018/rabetokotany.yml b/_data/dec2018/rabetokotany.yml new file mode 100644 index 0000000..550d9c4 --- /dev/null +++ b/_data/dec2018/rabetokotany.yml @@ -0,0 +1,12 @@ +fullname: Andriamarolahy Rabetokotany +goby: Marolahy +img: rabetokotany.jpg +links: + - + title: LinkedIn + url: https://www.linkedin.com/in/andriamarolahy-rabetokotany-a84986143/ +affiliation: + - + org: African Institute for Mathematical Sciences, Senegal + position: Master Coop Student +status: complete \ No newline at end of file diff --git a/_data/dec2018/sefara.yml b/_data/dec2018/sefara.yml new file mode 100644 index 0000000..97e1cea --- /dev/null +++ b/_data/dec2018/sefara.yml @@ -0,0 +1,21 @@ +fullname: Joseph Sefara +goby: Joseph +img: sefara.jpg +links: + - + title: Github + url: https://github.com/sefaratj/ + - + title: LinkedIn + url: https://www.linkedin.com/in/josephsefara/ + - + title: Project Website + url: https://www.speechtech.co.za +affiliation: + - + org: Council for Scientific and Industrial Research, South Africa + position: Junior Data Engineer + - + org: University of Limpopo + position: Masters Student +status: complete \ No newline at end of file diff --git a/_data/dec2018/toussaint.yml b/_data/dec2018/toussaint.yml new file mode 100644 index 0000000..e5c8b7c --- /dev/null +++ b/_data/dec2018/toussaint.yml @@ -0,0 +1,8 @@ +fullname: Wiebke Toussaint +goby: Wiebke +img: toussaint.jpg +affiliation: + - + org: Energy Research Centre, University of Cape Town + position: Data Scientist +status: complete \ No newline at end of file diff --git a/_data/jan2020/AreEB.yml b/_data/jan2020/AreEB.yml new file mode 100644 index 0000000..0d071d7 --- /dev/null +++ b/_data/jan2020/AreEB.yml @@ -0,0 +1,11 @@ +--- +fullname: Elisha Are +goby: Elisha +img: Elisha.jpg + + +affiliation: + - + org: SACEMA + position: PhD candidate +--- \ No newline at end of file diff --git a/_data/jan2020/Mthombothi.yml b/_data/jan2020/Mthombothi.yml new file mode 100644 index 0000000..8ac55e4 --- /dev/null +++ b/_data/jan2020/Mthombothi.yml @@ -0,0 +1,10 @@ +--- +fullname: Zinhle Mthombothi +goby: Zinhle +img: Mthombothi.jpg + +affiliation: + - + org: SACEMA-Stellenbosch University + position: Junior Researcher +--- diff --git a/_data/jan2020/azam.yml b/_data/jan2020/azam.yml new file mode 100644 index 0000000..5f2eef4 --- /dev/null +++ b/_data/jan2020/azam.yml @@ -0,0 +1,19 @@ +--- +fullname: James Azam +goby: James +img: james.jpg +links: + - + title: LinkedIn + url: https://www.linkedin.com/in/james-azam-6b5b00176/ + - + title: Twitter + url: https://twitter.com/james_azam/ + - + title: Research Gate + url: https://www.researchgate.net/profile/James_Azam/ +affiliation: + - + org: DST-NRF Center of Excellence in Epidemiological Modelling and Analysis, Stellenbosch University + position: PhD Candidate +--- diff --git a/_data/jan2020/bolton.yml b/_data/jan2020/bolton.yml new file mode 100644 index 0000000..4b21a87 --- /dev/null +++ b/_data/jan2020/bolton.yml @@ -0,0 +1,9 @@ +--- +fullname: Larisse Bolton +goby: Larisse +img: larisse.jpg +affiliation: + - + org: SACEMA + position: Postdoctoral Research Fellow +--- diff --git a/_data/jan2020/dominic.yml b/_data/jan2020/dominic.yml new file mode 100644 index 0000000..8aa299b --- /dev/null +++ b/_data/jan2020/dominic.yml @@ -0,0 +1,16 @@ +--- +fullname: Emanuel Dominic +goby: Emanuel +img: emanuel.jpg +links: + - + title: LinkedIn + url: https://www.linkedin.com/in/emanuel-m-dominic-a62763a0/ + - + title: ResearchGate + url: https://www.researchgate.net/profile/Emanuel_Muema +affiliation: + - + org: SACEMA + position: Junior Researcher +--- diff --git a/_data/jan2020/ebrahim.yml b/_data/jan2020/ebrahim.yml new file mode 100644 index 0000000..7505527 --- /dev/null +++ b/_data/jan2020/ebrahim.yml @@ -0,0 +1,5 @@ +--- +fullname: Tameez Ebrahim +goby: Tameez +img: ebrahim.jpeg +--- diff --git a/_data/jan2020/marijn.yml b/_data/jan2020/marijn.yml new file mode 100644 index 0000000..f6ff746 --- /dev/null +++ b/_data/jan2020/marijn.yml @@ -0,0 +1,9 @@ +--- +fullname: Marijn Hazelbag +goby: Marijn +img: marijn.jpg +affiliation: + - + org: SACEMA + position: Postdoctoral Research Fellow +--- diff --git a/_data/jan2020/napata.yml b/_data/jan2020/napata.yml new file mode 100644 index 0000000..7a6c062 --- /dev/null +++ b/_data/jan2020/napata.yml @@ -0,0 +1,13 @@ +--- +fullname: Lloyd Napata +goby: Lloyd +img: loynaps.jpg +links: + - + title: twitter + url: https://twitter.com/llonaps +affiliation: + - + org: Muzinda Hub + position: Software Developer. +--- diff --git a/_data/jan2020/pulliam.yml b/_data/jan2020/pulliam.yml new file mode 100644 index 0000000..bc4d46c --- /dev/null +++ b/_data/jan2020/pulliam.yml @@ -0,0 +1,16 @@ +--- +fullname: Juliet Pulliam +goby: Juliet +img: pulliam.jpg +links: + - + title: ICI3D + url: http://www.ici3d.org/ + - + title: SACEMA + url: https://www.sacema.org/ +affiliation: + - + org: SACEMA + position: Director +--- diff --git a/_data/jan2020/suboi.yml b/_data/jan2020/suboi.yml new file mode 100644 index 0000000..4413e36 --- /dev/null +++ b/_data/jan2020/suboi.yml @@ -0,0 +1,10 @@ +--- +fullname: Zenabu Suboi +goby: Zenabu +img: Suboi.jpg + +affiliation: + - + org: SACEMA + position: Masters Student +--- diff --git a/_data/jan2020/sulaimon.yml b/_data/jan2020/sulaimon.yml new file mode 100644 index 0000000..5ee9fe7 --- /dev/null +++ b/_data/jan2020/sulaimon.yml @@ -0,0 +1,13 @@ +--- +fullname: Tijani Sulaimon +goby: Tijani +img: tijani.jpg +links: + - + title: SACEMA + url: http://www.sacema.org/people/students +affiliation: + - + org: SACEMA + position: MSc Student +--- diff --git a/_data/jan2020/template.md b/_data/jan2020/template.md new file mode 100644 index 0000000..f1ec863 --- /dev/null +++ b/_data/jan2020/template.md @@ -0,0 +1,42 @@ +--- +fullname: Firstname Lastname +goby: Personalname +img: yourface.jpg +links: + - + title: some link + url: https://to.your.stuff/ + - + title: another + url: https://link.to.things/ +affiliation: + - + org: Some Company + position: Junior Dev. +--- +This is a template for some brief biographical information. The format is called YAML; see [this URL](http://yaml.org/spec/) for more information about formatting requirements. The directions below explain each variable. + +# Steps: + + 1. *Fork* the repository (there's a button on the main repository page) + 2. Make a *clone* to edit on your local machine, or access via the gitlab WebIDE + 3. Duplicate this file, in this folder (local machine, just use copy or cp; if using WebIDE, click on the vertical dots that appear when you hover over the folder to the left and create a new file, then copy-paste this file's contents). + 4. Make sure the new file name corresponds to your family name or surname, and change the extension to `.yml`. + 5. Fill in the elements in the YAML block above per directions below. + 6. Delete the text contents of this file. + 6. Create a merge request for your branch into the master branch. + 7. If there are any comments from the faculty indicating you need to make additional changes, make those changes in your fork and they will be automatically included in your merge request. + +# Required: + +Fill in your full name for *fullname*, and what you wish to be called during the workshop in *goby*. + +Add an image file to the `participants/jan2020` folder (not `_data/jan2020`, like where this file is), which is includes your face. Name this file in a way that its obviously connected to you, and put that file name for the *img* key. + +# Optional: + +If you want to provide any links (e.g., to your homepage, to your publication record), use the *links* element. This element should be a list, which each item having a *title* (the text that will be displayed) and *url* (the target link). + +If you have affiliations you want to include (e.g., employer, school or department), you can fill them as a list with each list element having an *org* and *position* (though *position* is an optional field as well). + +If you *don't* want those elements, delete them. \ No newline at end of file diff --git a/_faculty/bah.md b/_faculty/bah.md new file mode 100644 index 0000000..b7ff7bb --- /dev/null +++ b/_faculty/bah.md @@ -0,0 +1,16 @@ +--- +fullname: Bubacarr Bah +goby: Bubacarr +links: + - + title: google scholar + url: https://scholar.google.co.za/citations?user=Y_bXZfMAAAAJ + - + title: homepage + url: https://sites.google.com/aims.ac.za/bubacarr +img: bubacarr.jpg +affiliation: + - + org: AIMS South Africa + position: German Research Chair of Mathematics with specialization in Data Science +--- \ No newline at end of file diff --git a/_faculty/hladish.md b/_faculty/hladish.md new file mode 100644 index 0000000..964a1b9 --- /dev/null +++ b/_faculty/hladish.md @@ -0,0 +1,13 @@ +--- +fullname: Thomas J. Hladish +goby: Tom +links: + - + title: google scholar + url: https://scholar.google.com/citations?user=Ncv6hnMAAAAJ +img: tom.jpg +affiliation: + - + org: University of Florida + position: Research Assistant Scientist +--- \ No newline at end of file diff --git a/_faculty/maturure.md b/_faculty/maturure.md new file mode 100644 index 0000000..011ba45 --- /dev/null +++ b/_faculty/maturure.md @@ -0,0 +1,9 @@ +--- +fullname: Perceval Maturure +goby: Perceval +img: perceval.jpg +affiliation: + - + org: South African Centre for Epidemiological Modeling & Analysis + position: Technical Officer +--- \ No newline at end of file diff --git a/_faculty/pearson.md b/_faculty/pearson.md new file mode 100644 index 0000000..afbda5c --- /dev/null +++ b/_faculty/pearson.md @@ -0,0 +1,16 @@ +--- +fullname: Carl A. B. Pearson +goby: Carl +img: carl.jpg +links: + - + title: google scholar + url: https://scholar.google.com/citations?user=XKRJAXwAAAAJ +affiliation: + - + org: LSHTM + position: Research Fellow + - + org: SACEMA + position: Research Fellow +--- \ No newline at end of file diff --git a/_faculty/stoltzfus.md b/_faculty/stoltzfus.md new file mode 100644 index 0000000..bb41900 --- /dev/null +++ b/_faculty/stoltzfus.md @@ -0,0 +1,21 @@ +--- +fullname: Arlin Stoltzfus +goby: Arlin +img: arlin.jpg +links: + - + title: google scholar + url: https://scholar.google.com/citations?user=Q9fzhu4AAAAJ&hl=en + - + title: homepage + url: http://www.molevol.org/ + - + title: github + url: https://github.com/arlin + +affiliation: + - + org: Institute for Bioscience and Biotechnology Research (USA) + - + org: Office of Data and Informatics, Material Measurement Laboratory, National Institute of Standards and Technology (USA) +--- \ No newline at end of file diff --git a/_faculty/template.md b/_faculty/template.md new file mode 100644 index 0000000..d2ab831 --- /dev/null +++ b/_faculty/template.md @@ -0,0 +1,27 @@ +--- +fullname: Firstname Lastname +goby: Personalname +links: + - + title: some link + url: https://to.your.stuff/ + - + title: another + url: https://link.to.things/ +img: bubacarr.jpg +affiliation: + - + org: Some Company + position: Junior Dev. +--- +This is a template for some brief biographical information. The format is called YAML; see URL for more information about formatting requirements. The directions below explain each variable. + +Required: + +Fill in your full name for *fullname*, and what you wish to be called during the workshop in *goby*. + +Optional: + +If you want to provide any links (e.g., to your homepage, to your publication record), use the *links* element. This element should be a list, which each item having a *title* (the text that will be displayed) and *url* (the target link). + +If you have affiliations you want to include (e.g., employer, school or department). \ No newline at end of file diff --git a/_includes/applications.md b/_includes/applications.md new file mode 100644 index 0000000..cf289df --- /dev/null +++ b/_includes/applications.md @@ -0,0 +1,2 @@ +{% if site.taking_apps %}Applications {% include lo.md tx='are now open' l=site.taking_apps.url %} for {{site.nextdate}}! Application reviews starting ***{{site.taking_apps.end}}*** - rolling admissions after then; see application site for full details. +{% endif %} diff --git a/_includes/embedslides.html b/_includes/embedslides.html new file mode 100644 index 0000000..b047611 --- /dev/null +++ b/_includes/embedslides.html @@ -0,0 +1,3 @@ + + +Click to view seperately... \ No newline at end of file diff --git a/_includes/faculty.md b/_includes/faculty.md new file mode 100644 index 0000000..3a9d500 --- /dev/null +++ b/_includes/faculty.md @@ -0,0 +1,6 @@ +{%- capture nameinfo -%}![{{ include.profile.fullname }}]({{ include.path | default: '' }}{{ include.profile.img }} "{{ include.profile.fullname }}"){% endcapture -%} +- {% if include.profile.status == 'complete' %}[{{ nameinfo }}]({% assign cert = include.profile.img | split: '.' %}{{ cert[0] }}.pdf){% else %}{{ nameinfo }}{% endif %} + * {{ include.profile.fullname }}{% if include.profile.goby %} (_{{ include.profile.goby }}_){% endif %}{% if include.profile.links %} + * {% for lk in include.profile.links %}[{{ lk.title }}]({{ lk.url }}){:target="_blank"}{% if forloop.last == false %}, {% endif %}{% endfor %}{% endif %} +{% for aff in include.profile.affiliation %} * {{ aff.org }}{% if aff.position %}, _{{ aff.position }}_{% endif %} +{% endfor %} \ No newline at end of file diff --git a/_includes/footer.html b/_includes/footer.html new file mode 100644 index 0000000..f292bc1 --- /dev/null +++ b/_includes/footer.html @@ -0,0 +1,27 @@ +
+ +
+ +
+
+ +
+ +
+

{{ site.description }}

+
+
+ +
+ {% include footer_logo.html target='logo-UF.svg' %} + {% include footer_logo.html target='logo-africom.png' alt='USAFRICOM' %} + {% include footer_logo.html target='logo-AIMS.png' alt='AIMS South Africa' %} + {% include footer_logo.html target='logo-humboldt.png' alt='Humboldt Foundation' %} + {% include footer_logo.html target='logo-SACEMA.svg' alt='SACEMA' %} +
+ +
+
diff --git a/_includes/footer_logo.html b/_includes/footer_logo.html new file mode 100644 index 0000000..9158327 --- /dev/null +++ b/_includes/footer_logo.html @@ -0,0 +1 @@ + diff --git a/_includes/head.html b/_includes/head.html new file mode 100644 index 0000000..9afc65a --- /dev/null +++ b/_includes/head.html @@ -0,0 +1,16 @@ + + + + + {% if page.title %}{{ page.title | escape }} - {% endif %}{{ site.longtitle | escape }} + + + + + + {% include html_code.html %} + diff --git a/_includes/header.html b/_includes/header.html new file mode 100644 index 0000000..8a194bc --- /dev/null +++ b/_includes/header.html @@ -0,0 +1,32 @@ +
+ +
+ + + {% include logo-SEAMS.svg %} + {{ site.title }} + {{ site.nextdate }} + + + + + +
+ +
diff --git a/_includes/html_code.html b/_includes/html_code.html new file mode 100644 index 0000000..41c5b99 --- /dev/null +++ b/_includes/html_code.html @@ -0,0 +1,12 @@ + + + + + + + + + + + + diff --git a/_includes/icon-github.html b/_includes/icon-github.html new file mode 100644 index 0000000..e501a16 --- /dev/null +++ b/_includes/icon-github.html @@ -0,0 +1 @@ +{% include icon-github.svg %}{{ include.username }} diff --git a/_includes/icon-github.svg b/_includes/icon-github.svg new file mode 100644 index 0000000..4422c4f --- /dev/null +++ b/_includes/icon-github.svg @@ -0,0 +1 @@ + diff --git a/_includes/icon-gitlab.html b/_includes/icon-gitlab.html new file mode 100644 index 0000000..922ef21 --- /dev/null +++ b/_includes/icon-gitlab.html @@ -0,0 +1 @@ +{% include icon-gitlab.svg %}{{ include.username }} \ No newline at end of file diff --git a/_includes/icon-gitlab.svg b/_includes/icon-gitlab.svg new file mode 100644 index 0000000..e47423e --- /dev/null +++ b/_includes/icon-gitlab.svg @@ -0,0 +1 @@ + diff --git a/_includes/icon-twitter.html b/_includes/icon-twitter.html new file mode 100644 index 0000000..fa92dbf --- /dev/null +++ b/_includes/icon-twitter.html @@ -0,0 +1 @@ +{{ include.username }} \ No newline at end of file diff --git a/_includes/icon-twitter.svg b/_includes/icon-twitter.svg new file mode 100644 index 0000000..dcf660e --- /dev/null +++ b/_includes/icon-twitter.svg @@ -0,0 +1 @@ + diff --git a/_includes/lo.md b/_includes/lo.md new file mode 100644 index 0000000..cbb70be --- /dev/null +++ b/_includes/lo.md @@ -0,0 +1 @@ +[{{ include.tx }}]({{ include.l }}){:target="_blank"} \ No newline at end of file diff --git a/_includes/logo-SACEMA.svg b/_includes/logo-SACEMA.svg new file mode 100644 index 0000000..b5232b4 --- /dev/null +++ b/_includes/logo-SACEMA.svg @@ -0,0 +1,540 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_includes/logo-SEAMS.svg b/_includes/logo-SEAMS.svg new file mode 100644 index 0000000..5adca47 --- /dev/null +++ b/_includes/logo-SEAMS.svg @@ -0,0 +1,18 @@ + + + + + + + + + + + + + + + + diff --git a/_includes/logo-UF.svg b/_includes/logo-UF.svg new file mode 100644 index 0000000..c8f9001 --- /dev/null +++ b/_includes/logo-UF.svg @@ -0,0 +1,27 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/_includes/oldlink.md b/_includes/oldlink.md new file mode 100644 index 0000000..d453dfd --- /dev/null +++ b/_includes/oldlink.md @@ -0,0 +1 @@ +[{{ include.tx }}](http://aims-ghana.github.io/cams/{{ include.l }}){:target="_blank"} \ No newline at end of file diff --git a/_layouts/default.html b/_layouts/default.html new file mode 100644 index 0000000..e4ab96f --- /dev/null +++ b/_layouts/default.html @@ -0,0 +1,20 @@ + + + + {% include head.html %} + + + + {% include header.html %} + +
+
+ {{ content }} +
+
+ + {% include footer.html %} + + + + diff --git a/_layouts/page.html b/_layouts/page.html new file mode 100644 index 0000000..1d757bc --- /dev/null +++ b/_layouts/page.html @@ -0,0 +1,10 @@ +--- +layout: default +--- +
+ +
+ {{ content }} +
+ +
diff --git a/_layouts/people.html b/_layouts/people.html new file mode 100644 index 0000000..d7e3dc3 --- /dev/null +++ b/_layouts/people.html @@ -0,0 +1,6 @@ +--- +layout: page +--- +
+{{ content }} +
\ No newline at end of file diff --git a/_layouts/person.html b/_layouts/person.html new file mode 100644 index 0000000..dea0648 --- /dev/null +++ b/_layouts/person.html @@ -0,0 +1,10 @@ +--- +layout: default +--- +
+ +
+ {{ content }} +
+ +
\ No newline at end of file diff --git a/_layouts/post.html b/_layouts/post.html new file mode 100644 index 0000000..3a0fb52 --- /dev/null +++ b/_layouts/post.html @@ -0,0 +1,15 @@ +--- +layout: default +--- +
+ +
+

{{ page.title }}

+

{% if page.author %} • {% endif %}

+
+ +
+ {{ content }} +
+ +
diff --git a/_locconfig.yml b/_locconfig.yml new file mode 100644 index 0000000..09d0532 --- /dev/null +++ b/_locconfig.yml @@ -0,0 +1,9 @@ +# Welcome to Jekyll! +# +# This config file is meant for settings that affect your whole blog, values +# which you are expected to set up once and rarely need to edit after that. +# For technical reasons, this file is *NOT* reloaded automatically when you use +# 'jekyll serve'. If you change this file, please restart the server process. + +# Site settings +title: 'LV: SEAMS Workshop v5' diff --git a/_practical/01_design.md b/_practical/01_design.md new file mode 100644 index 0000000..4344efd --- /dev/null +++ b/_practical/01_design.md @@ -0,0 +1,40 @@ +--- +slug: design +title: Project Design & Planning +--- + +We're going to get into small groups for a few exercises to get you thinking about design. For all of these exercises, we will give you "prompts" - these describe in plain language some task. The challenge in each problem will not be the task itself, but rather the analysis of the task in terms of requirements, design, and planning. + +# Activity 1: Design Telephone + +Get into groups of 3 (or more, but not less than 3) and decide on a cycle - who passes to whom, forming a loop. You'll each be given an initial prompt - keep it secret! + +First, each of you translate your prompts in _pseudocode_. Once each of you are done, pass the pseudocode to the next person; don't let them see the prompt. + +Second, from the pseudocode, each of you write down a _process flow diagram_. Again, once each of you are done, pass the process diagram to the next person; don't let them see the pseudocode. + +Third, from the process diagram, each person should write down a plain language description of a task. + +Finally, reveal the previous steps back to the original prompt - does the final prompt match the original? Where did the mistranslation occur? Why? + +# Activity 2: Design Iteration + +Get into new groups, this time of 2-3. Each group will be given prompts in a series, representing an evolving task (akin to what we closed out the discussion session with). For each prompt you will need to prepare a (or revise a previous) _design diagram_ for solving the problem. + +How did the prompts evolve? Did the changes have a big impact on your design? If they did, how might you have approached the earlier stages differently? + +# Activity 3: Working Collaboratively + +Get into new groups of 3-4; each group will be given an overall task, broken into three parts. + +For the first pass, each group member will work independently on a part, _without communicating with their team_. Then, the team will try to put their pieces together. + +What problems did you encounter putting the pieces together? What might you do differently? + +Take a moment to write those down, and to make a plan about how you could deal with them. + +Okay, got a plan? + +Now we're going trade problems between teams. You team is again to work independently, then put your pieces together - but this time first you get to look at your pieces, chat for short period of time, perhaps write down some things, pick who does which, and then work independently. + +When you regroup to assemble your pieces this time, how did things differ? What did *you* do differently, and what effect do you think it had? \ No newline at end of file diff --git a/_practical/02_workspace.md b/_practical/02_workspace.md new file mode 100644 index 0000000..aa3cdb4 --- /dev/null +++ b/_practical/02_workspace.md @@ -0,0 +1,32 @@ +--- +slug: workspace +title: Workspace Organization & Tools +--- +Scenario: +Your supervisor has asked you to take over a project from a former lab member. It's a bit of a mess, and needs to be cleaned up for a publication. Here's the request you received by email: + +> Dear NewLabMember, +> +> Thank you for agreeing to pick up the pieces on this project. My postdoc, John Snow, was working on this, but he had to drop it abruptly to deal with some cholera issue in London. +> +> I'm providing everything he gave me in the attached tgz file, but it's a bit of a mess. It's a basic case fatality ratio analysis for COVID-19 in South Africa. It looks like there's a shell script to download the data, but the data are also included, so you may or may not need the script. There are also a few versions of the R code to make the figures--I've marked the most complete one as "good", but maybe that's not the best adjective for it . . . it doesn't actually run. +> +> I think John was doing this in RStudio, and running chunks of code in a piecemeal way, so probably the issue is that everything is there, but not necessarily in the right order. It looks to me like line 20, where the date column is cast as dates, needs to be moved up before any plotting is attempted, but please verify. We're going to be including this in a paper we're submitting, so it needs to be in a public repository, and organized well enough that reviewers will understand without a lot of effort. So please do whatever needs to be done to clean this up. +> +> Best wishes, +> Tom + + +The file attached to the email can also be [downloaded here](cfr_project.tgz): + +Required steps: +0. Create a new repository. Put something? everything? in it. Set up the repo locally and on a remote service (e.g. github, gitlab). +1. What problems do you see? Create one or more issues on your remote repository. +2. Begin solving the organizational problems, committing with each solution and marking the corresponding issues as solved. + +Things to consider doing: +- Add/remove files from repo as appropriate +- Create a directory hierarchy that reflects the relationships between the files in the projects +- Set up shared directories with your collaborators for input/output files using e.g. Dropbox +- Improve documentation +- Refactor the source code so that it has clearer structure, is more versatile, is easier to modify, etc. \ No newline at end of file diff --git a/_practical/03_reuse.md b/_practical/03_reuse.md new file mode 100644 index 0000000..b2a4a74 --- /dev/null +++ b/_practical/03_reuse.md @@ -0,0 +1,22 @@ +--- +slug: reuse +title: Reuse & Reusability Practical +--- + +## 1. Write an installable hello world package + +Write a "hello world" a library/module/package (whatever the term is in your language of choice). The only functionality this package needs to have is a function `helloworld()`, taking no arguments, and printing the phrase "hello world" to the screen. Make sure it works. + +Now, research how to package the code in your chosen language, and do it! Here are some resources for [python packages](https://python-packaging.readthedocs.io/en/latest/) and [R packages](http://r-pkgs.had.co.nz/) (also [here](https://r-pkgs.org/)). When you're done, pair up with someone and see if you can successfully install each other's packages. You may want to: + + 1. Have your code available as a repository, so your friend can access it. + 2. Have a README explaining how to install your package, and how to use it. + +If your partner can't install it without extensive help from you, that may mean your documentation is bad. + +## 2. Write a not-so-hello world package + +Building from yesterday's practical (organizing some messy code), take your organized code (or work from one of the [instructor solutions](https://github.com/SEAMS-Workshop/workspace_practical)), and turn it into a package. A few considerations: + + - What goes in the "library" part? Why? + - If something doesn't go in the library part, how are people going to get it otherwise? \ No newline at end of file diff --git a/_practical/04_io.md b/_practical/04_io.md new file mode 100644 index 0000000..a35b2b2 --- /dev/null +++ b/_practical/04_io.md @@ -0,0 +1,183 @@ +--- +slug: io +title: Input & Output (IO) +--- + +This exercise presents you with a challenge that involves accessing, understanding, and writing data using various methods. You will get to use +* CSV (comma-separated values) for tabular data +* language-specific binaries or serializations + * R: RDS files + * Python: pickles +* an SQL database +* an Excel file + +### The story +![Scenario: workflow with Pat's database and script](io-practical-figure.jpg) + +You are part of a multi-author team preparing a revised manuscript on the COVID-19 epidemic in southern Africa. Unfortunately, a key team member, Pat, moved on to another job last September, and is not able to update plots from the original manuscript, like this plot which only goes through August 2022. + +You have been tasked with updating and expanding the plots by +* Adding data through the end of 2022 for South Africa +* Making an additional plot with new cases per million for all southern African countries +* Adding vaccinations for South Africa +* Making this into a supplementary data repository + +That sounds hard, but Pat has made this easier, by sending you 2 files with missing information, along with a brief email with instructions + +> Hello! I heard that you are going to add the new data and clean this up for publication. +You probably won't be able to get the db connection to work in the script, but that's +no problem, just launch "sqlite3 AfricaCOVID.db" and run the SELECT statements for +whatever countries you want. If you type ".header on", ".mode csv", and ".once +'myfilename.csv'", then the results of the next SELECT statement will be written to the +named csv file, and then you can work with the data directly. +> +> Jan provided 2 data files to make the requested updates. The Excel file +(newer-african-data.xslx) has data on cases and deaths from October 2022 onward. Beware +that Excel can't keep dates straight. The vax data are in african-vax-data.rds. Both +of these have data for all the African countries. +> +> Everything else should work fine. Good luck, +> +> Pat + +[The attachment to Pat's email.](files-from-Pat.zip) + +Pat's script below has just 11 lines of code in R. It uses a database connector that is no longer supported, but Pat's email suggests a way to deal with that. + +```R +library("BadRSQLite") +library("ggplot2") + +# don't need this anymore bc ISO codes for Region are in ccodes table +# region <- c("AGO", "BWA", "LSO", "MWI", "MOZ", "NAM", "ZAF", "SWZ", "ZWB", "ZWE") + +# get the db link and query it for southern Africa data +mydblink <- dbConnect(BadRSQLite::SQLite(), "AfricaCOVID.db") +regiondat <- dbGetQuery(mydblink, "SELECT COVID.* FROM COVID JOIN ccodes ON + COVID.iso_code=ccodes.ISO3 WHERE ccodes.Region='Southern Africa';") +dbDisconnect(mydblink) + +# make the date column into R dates, numeric columns into R numeric type +regiondat$date <- as.Date(regiondat$date) +regiondat[5:16] <- apply(regiondat[5:16], 2, as.numeric) +zafdat <- subset(regiondat, iso_code = 'ZAF') + +# plot the ZAF data with new cases and deaths, save as file +p <- ggplot(zafdat, aes(x = date, y = new_cases_smoothed_per_million, + group = location)) + + geom_line() + scale_x_date(date_breaks = "1 month", date_labels = "%b") + + ylab(label = "New cases or deaths per million, smoothed") +p2 <- p + geom_line(aes(y = new_deaths_smoothed_per_million), colour= "red") +ggsave("zaf-plot.jpg", p2, width=20, height=8, units="cm") + +# plot the data for all southern African countries +p3 <- ggplot(regiondat, aes(x = date, y = new_cases_smoothed_per_million, + group = location, color = location)) + + geom_line() + scale_x_date(date_breaks = "1 month", date_labels = "%b") + + ylab(label = "New cases per million, smoothed") +# ggsave("southern-plot.jpg", p3, width=20, height=8, units="cm") + +``` + +### Python version of the story + +The Python version of the story is the same, except the script is in Python, and there is a pickle file instead of an RDS. + +```Python +# import libraries +import badsqlite3 +import pandas as pd + +# setup db connection +dbpath = os.path.abspath("AfricaCOVID.db") +con = badsqlite3.connect(dbpath) +cur = con.cursor() + +# get all the southern africa data +result = cur.execute("SELECT COVID.* FROM COVID JOIN ccodes ON \\ + COVID.iso_code=ccodes.ISO3 WHERE ccodes.Region='Southern Africa'") +regiondat = pd.DataFrame(result.fetchall()) + +# name the columns +regiondat.columns = ["iso_code", "continent", "location", "date", "total_cases", + "new_cases", "new_cases_smoothed", "total_deaths", "new_deaths", + "new_deaths_smoothed", "total_cases_per_million", "new_cases_per_million", + "new_cases_smoothed_per_million", "total_deaths_per_million", + "new_deaths_per_million", "new_deaths_smoothed_per_million"] +regiondat.head(10) + +# this part doesn't work but it's close +# plot results +regiondat.set_index('date', inplace=True) +regiondat.groupby('location')['new_cases_smoothed_per_million'].plot(legend=True) + +``` + +### What you'll need to complete this task + +Here is what Pat and the team have provided +* the script ```make-SA-plot.R``` +* the sqlite3 database ```AfricaCOVID.db``` (4.9 MB file) +* the Excel file with new data ```newer-african-data.xlsx``` +* the RDS (or pickle) file with vax data ```african-vax-data.rds``` + +And you will need to supplement that by +* using your skills in R or Python +* looking things up online +* working in a programming environment like RStudio or Python Notebook +* installing [pre-compiled binary of SQLite3](https://www.sqlite.org/download.html) + * for a beginner lesson and a test database, see [Software Carpentry's SQL lesson](https://swcarpentry.github.io/sql-novice-survey/) + +### How to proceed + +The goal is to get those updated plots ready for submission, along with a data package (if you have time). There are many ways to do this. The problem is set up to force you to use multiple IO approaches. + +Whatever approach you take, remember the following: (1) make a stepwise plan, (2) check what you are doing along the way, i.e., use available tools to examine data sources so that you know what is happening, and (3) don't get stuck, and be prepared to revise your plan. + + + + + +### Checkpoints + + + +Who is having issues or would like some help with +* accessing the database? +* getting data out of the database into another form? +* the plotting code? +* the RDS or pickle file? +* the Excel file? +* merging the old and new data sources? + +### Questions + +How difficult is it to get data out of an SQL db, an Excel file, a csv file, or a language-specific data serialization format? What makes a format more accessible? What makes it easier? + +How difficult is it to use the data once you get it? Is there a difference between how easy it is to get access to data, and how easy it is to use the data effectively? How? What is the basis of that. + +Which way of storing and transferring data is the most robust? Which is likely to be in use 10 years from now? + +For simple tables, a csv file is usually the best. When would you consider a binary serialization? An SQL database? An Excel file? + +How did you decide on filenames? How did you decide on the number and content of files to make? + +What did you learn about formats from this exercise? What would you do differently in the future based on what you learned? diff --git a/_practical/05_hpc.md b/_practical/05_hpc.md new file mode 100644 index 0000000..535a25e --- /dev/null +++ b/_practical/05_hpc.md @@ -0,0 +1,19 @@ +--- +slug: hpc +title: High Performance Computing +--- + +## Hello, Hello, Hello ... + +Get into pairs, ensuring each group has someone with access [CHPC](http://wiki.chpc.ac.za/). + +Submit a size 10 [array job](https://duckduckgo.com/?q=pbs+pro+array+job) to CHPC, for some helloworld of your choice. Have that helloworld code: + + - Greet with "Hello, job N!", where $N$ is the position in the array job. + - record that result for each point in the array + +Collect those resulting greetings, by when they happened in realtime, into a single file. + +## Not-so-helloworld + +Return to your reuse practical results (or use the instructor [examples](https://github.com/SEAMS-Workshop/reuse_practical)). Remember how we did these analysis for ZAF? Figure out a way to use an array job, plus that existing code, to get the results for several countries in Southern Africa. \ No newline at end of file diff --git a/_project/01_design.md b/_project/01_design.md new file mode 100644 index 0000000..4444dc3 --- /dev/null +++ b/_project/01_design.md @@ -0,0 +1,49 @@ +--- +slug: design +title: Project Design & Planning +--- + +# REQUIRED + +- Presentation: + * Copy and revise your slide from the warmup. You can add one other slide. Add it to the folder where you editted the presentation for this morning's warmup. + * Uses today's the discussion of requirements, design, and planning to help you frame the presentation: what should your project do, how should it work, and what's your plan to make that happen next week? + * Use at least one visualization (*e.g.*, the flowchart you develop in response to the prompt below) to help explain your project. + * Spend no more than 20 minutes on this. You may want to do it after you work through some of the optional items below. + +# PRIORITIZE THOSE THAT APPLY TO YOUR PROJECT + +- Make a record of your requirements + * For the tasks you complete below, add a record of them to wherever you're keeping your project. For example, they could become part of a README in your repository, a design document, elements of a supplementary information draft, etc. +- Answer the 5WH (Why, Where, Who, What, When and How) questions for your project. E.g. "Who is using the project?" "What do they use it to do?" "How do they use it?" - try to be specific with both question and answers. +- For whatever tool you use to manage your project, try to layout a project plan - big picture milestone steps, detailed tasks associated with achieving those, marked with who needs to do what by when, etc. +- Identify project scope: + * In 1-3 sentences, what does your project *do* now? + * Imagine that you have completed this workshop, including the hack-a-thon on your project; write the new version of those 1-3 sentences. Keep in mind: that description might not change at all! If it won't change, write 1-3 sentences about what *will* change (e.g., performance). + * Are there similar projects (that is, performing mostly the same function, but perhaps in a different language or for different inputs) you can learn from or build on? Do an internet search as needed. + * Who will interact with your software? Think broadly about the definition of "interact" - for example, who might see the results? Who else might change the code? Who might run the software? + * What constraints are there on the user interface? +- I/O specific requirements: + * What data does your project require (inputs)? + * Where/how will you obtain it? + * What are the outputs from your project? + * What data/file formats will you need to work with? +- Divide and conquer: + * Identify 3-6 subproblems that your project can be divided into + * What is the most natural order in which to tackle the subproblems? + * Easist first? Hardest? From the interface in, or following the flow of information? + * Which can be implemented independently? Do some absolutely have to be completed first? + * How will you verify that specific subproblems have been solved? +- Draw a flowchart of the problem your project solves and its parts. + * Identify which steps each of your detailed requirements apply to. + * Are the steps that do not have detailed requirements associated with them? +- Technical requirements: + * What are the external technologies (for example, random number library, SQL database for recording data) your project uses? Or could use? Do an internet search as needed. + * What do you need to know/learn in order to complete the project? + * What platforms (*e.g.* OSX, Windows, HPC) should your project work on? +- If the project is substantially completed, what things do you think should have been done differently? +- Validation / Testing: + * How could you test that specific requirements have been satisfied? As in, what comparisons would you make (don't worry about what framework would you use)? + * To adequately & practically test your project, do you need to automate tests? +- Scientific Requirements: + * What are the specific science-related concerns for your project? diff --git a/_project/02_workspace.md b/_project/02_workspace.md new file mode 100644 index 0000000..2ed565a --- /dev/null +++ b/_project/02_workspace.md @@ -0,0 +1,38 @@ +--- +slug: workspace +title: Workspace Organization & Tools +--- + +# *REQUIRED*: File System Organization + + - Create *at least* one git repository for your project (any hosting service is fine), but don't worry about adding anything yet. If your project can be reasonably divided into core, reuseable pieces (generic analyses, e.g.) and particular application(s) (figure covering particular time period for a report, series of different experiments, e.g.), consider creating multiple repositories, for example one for the core components and others for specific applications. + - Arrange the project in your local filesystem, and connect the pieces to relevant remote services (e.g., you might be using Dropbox to share inputs or outputs). Think about project needs: what inputs need to be shared? what outputs? what is the core software? how will this project be used on other platforms (e.g., collaborators machines, super computer)? Translate these into a directory structure, and identify the need for any local configuration files. + - Write a README that explains the project layout within the filesystem (e.g., where inputs and outputs end up, what different parts of the source code cover). Also explain what SHOULD and SHOULD NOT be in the repository, as well as who will use the repository and how. Include the README file in the repository. + +# Documentation for Project Organization + + - Write a setup "script" for your project. This should just be a series of steps in pseudo-code English covering what needs to happen to make a new computer ready to work on / use the project. These steps should be comprehensible to a new collaborator on the project. Make note of areas where this is currently more complicated than you like, and could potentially be simplified. + + - Write a platforms overview for your project. + * What operating systems does the project *run* on *now*? + * What settings do you *need* it to run in? + * Which ones do you *want* it to run in? E.g., your project is on Windows machine, collaborator wants to run it in Linux. + * What system infrastructure does your project need *now* (e.g., Python / R interpretter, C/C++ compiler, database program, specific libraries)? + * Which of those dependencies do you *need* to remove (or which new ones do you need to add)? Explain why in a sentence or two for these needs and wants. + + - Write a collaboration overview for your project. + * How does development for your project work *now*? How many people can make changes to code? to input? to requirements (*i.e.*, the needs / demands / constraints etc. you might have defined during yesterdays project work)? + * How do those people communicate needed changes, or accomplishment of work? How does the team track these communications? + * How many people are planned for the team in the *future*? What role will those future collaborators play? What is the plan for bringing them into the project? + + - Relate your answers to the previous question to your process diagrams or pseudo-code from yesterday's project work. Which steps rely on which capabilities? Which determine organizational choices? + +# Tools + + - List the dependencies for your project (e.g., R libraries you use, nodejs packages, C/C++ headers)? What has to be done when they are updated? Research via the web the options you have for *dependency management*. + + - List the templating tools for the language(s) associated with your project. That is, tools which build code skeletons automatically. + + - The tool `make` and Makefiles are useful approach to documenting the relationships between various parts of your project (see [this example](https://opensource.com/article/18/8/what-how-makefile)). Try writing a makefile for the dependencies in your project + + - List programs you use to edit code (of any kind). What special features does those programs offer to help you with your coding task (compared to editing with just a plain text editor)? What do you like about these tools? What do you wish they did differently (or what more they did)? \ No newline at end of file diff --git a/_project/03_reuse.md b/_project/03_reuse.md new file mode 100644 index 0000000..0283d18 --- /dev/null +++ b/_project/03_reuse.md @@ -0,0 +1,70 @@ +--- +slug: reuse +title: Reuse & Reusability +--- + +## REQUIRED: Identify a reused/reusable part of your project + +Thinking about your project, identify some part of it that either was separately written by you for some other work and reused *OR* that is likely to be so in the future. Was/is/will that part in a library of some sort, or is it a copy-paste-tweak situation? If it's already usable like a library, how easy was that? What improvements might be made? If not, what would need to make it more library-like? + +## Reuse of your project + +### Users + +Thinking about your project as a whole or perhaps some element of it (either present currently, or planned as step outlined in pseudocode or a flow diagram): + + * For your future self: aside from the required item above, how could some other parts of your code be used by yourself in other projects? + * Beyond you: who are your target users or stakeholders (be as specific as possible)? What about your immediate co-workers? What about other people in the same field? In other fields? + * For those other people: what is going to make your module attractive to them? + * Write a few sentence about what your package does, then use those to search the web for code (in the same or other languages) that provide similar capabilities. What did you learn? + +### Niche / Capabilities + +If there is a reusable element, what problem is it solving? Is it a whole new idea? A better performing version of an existing idea? A customization for a particular setting? + +### Technical Steps + + * find out how and where packages are distributed in your preferred language, e.g., CRAN for R, _but not exclusively_. Try to identify multiple routes. If relevant, create account(s) with pertinent service(s). + * Leaning into the workspace and planning skills from previous days: create issues for discrete steps that need to happen to make your project (or elements of it) into a distributable entity. + * Research the mechanics of package generation in your preferred language + - identify a source of guidelines or best practices and bookmark that + - install tools / template libraries / etc that can help you generate a package; repeat the helloworld package practical from today using those tools. + * Recalling what you learned from workspace organization + - now that you know more about package generation for your preferred language, are they any particulars about filesystem arrangement? How do they work with (or against) choices you made yesterday? + - In addition to directory structure, are there are system configuration elements (e.g., environment variables, program aliases) that are required for packaging? Or for installing the resulting package properly for you intended users? What's available to manage that? + * Do an inform pro/con list. Now that you have imagined a package and explored the tools and best practices for generating and distributing packages: + - what extra work is required for you to make a package? + - what are the costs and benefits? + - where on the spectrum of reuse does your work fall? Is there a small, generic tool? Is it a large pipeline that demonstrates an overall workflow, but would entail lots of tweaking to actually reuse? + +## Parts of your project that might be replaced with existing modules + +This assumes that you know how to find packages for your preferred language and platform. + + * Identify replaceable components in your project. + - Thinking back to a pseudocode or flow diagram version of your project, are there steps that you can describe succinctly (in English, as single step in the flow), but that you have done quite a bit of coding to actually accomplish? These are candidates for replacement! + - List 3+ such points in your project, and write a "requirements" style description of them. + - Using that description, poke around on the web. Try to find code or a tool (in any language) that does what you want. + - What extra functionality would you get from this tool over how you do it currently (e.g., handling errors or exceptions)? Is it going to make your life easier? What are some downsides? + * Map out the steps to replace part of your code with an imported module + - does this add further dependencies? Is that a problem? How do you decide? + - How much rewriting will you have to do to use this tool? E.g. changing the kind of objects passed around (in few places? a lot of places?), changing (vs just deleting) lots of code? + - how will you declare this dependency to potential users? + +## Ways to extend your project with existing modules + +This assumes that you know how to find packages for your preferred language and platform. + + * Write down 3 ways that you might want to extend your project with new functionality. Explore ways to implement that functionality using existing modules. For instance + - IO. Maybe you want to store outputs in a database instead of ad hoc files. Maybe you you want to input JSON instead of ad hoc files. Are there modules for that? + - Estimation methods. Are there some other ways to do parameter estimation, perhaps more powerful or flexible than what you are doing? + - Graphical user interfaces. Would your code benefit from e.g. a web interface? What's the easiest way to do that? + * Thinking about other tools your hypothetical package might be used with - what are their interfaces? Is your interface written with the same approach? What new way of thinking would potential users have to learn to combine your library with others? Are there ways to make your interface more similar to that of other libraries a scientist would commonly use alongside your work? + +## Reuse Setting + + * Where do you imagine your code being reused? As a command line tool, as a package within some larger program, ...? What are the implications of those settings? + +## Testing + + * How testing is relevant to reuse? If someone wants to extend your work (or you want to extend other work), how can you make sure you don't break that code? \ No newline at end of file diff --git a/_project/04_io.md b/_project/04_io.md new file mode 100644 index 0000000..97b8415 --- /dev/null +++ b/_project/04_io.md @@ -0,0 +1,49 @@ +--- +slug: io +title: Input & Output (IO) +--- + +## REQUIRED + +Tomorrow, you will need to re-present your project. Recall the general feedback on the *purpose* of these: to think of your work from the perspective of how it is *engineered* to acheive your results, and less about the results / analysis per se. + +Spend _some_ time working on preparing that today; there will be some additional time tomorrow and you can work on it outside of formal course time, and we do want you to spend some time thinking about the prompts below relative to inputs. Express your project in terms of the flow from start to finish AND identify what element of that you want to work on next week. "Work on" might take many forms - e.g. it could be replacing some element with a library, instrumenting some step to understand how long it takes, documenting code to make it more reuseable, and so on. + +But: be clear about what the *outcome* of that work would be if accomplished AND have a plan that has incremental, small steps. That is, have the work plan start with step that you can think can accomplish in a _very_ short period of time: a morning at most. Assemble your plan out of several such steps. + +## Code vs Input + + * Does your project have "code" currently that might alternatively be thought of as input? *E.g.*, parameter or configuration values that are included directly in your scripts or source code, instead of in input files. If so, make an inventory of those files / a tabulation of the parameters / etc: some sort of key as to what's currently being hard coded. + * For those cases, do you find yourself regularly changing those values, *e.g.* to run a new scenario? If other people were to use your code, might they want to change those values? What is the "nature" of that data: key-value, tabular, ...? Annotate the above list with those conclusions. + +## Kinds of Input & Output + + * List your inputs and outputs, and label those data with their best fit as tabular, relational, hierarchical, key-value, or human-oriented (*e.g.*, a plot or sound file). + * For your inputs and outputs, which are general purpose formats (*e.g.*, csv, json, sqlite, protobuf) with libraries for many languages, specialized (*e.g.*, rds, docx) with application-specific access, or custom (*e.g.*, human readable, but with specialized parsing rules)? What are your reasons for using general vs specialized vs custom formats? + * For your inputs and outputs, which are human-readable (plaintext) vs machine-only readable (binary)? What are your reasons for using plaintext vs binary formats for different parts of your project? + +## Intermediate Results + + * Compared to your project overall outputs, are there intermediate files that are only used internally to your project? Thinking of your project in pseudocode or a flow-diagram, what steps are those files associated with? + * Does your project have a "resume" capability? If so, how do you implement it? If not, how might it benefit from one? + * Do you cache any intermediate results? If so, why? + +## Testing & Validation + + * Which of your project requirements specifically concern an input or output file feature? *E.g.*, must read / write particular format, size, ...? Or more generally the creation or consumption of specific data in specific formats? + * Does your project include in testing of inputs or outputs? *E.g.*, validation of inputs, checking for missing data, confirmation of output consistency with a validation standard, ...? If not, have you ever had to troubleshoot issues to do with invalid inputs or outputs? Would a validator have been useful for that troubleshooting? + +## Amounts & Locations + + * How much input does your project rely on? Estimate in kilobytes, Mbs, Gbs, (Tbs?) as appropriate. + * ...how much output does it create? Again estimate the amount. + * Is the input used or output created by your project all local? Or does some travel over a network (e.g. from a supercomputer to your machine, to users over the internet, shared to collaborators, ...)? + * How much time does your project spend loading data--*e.g.*, reading in a csv vs how much time the program spends analyzing the information in the file? If you don't know, how might you measure this? + * How much time does your project spend writing data--*e.g.*, generating and saving a plot vs generating the time series being plotted. If you don't know, how might you measure this? + +## Sharing + + * Are your raw inputs shared? Cleaned up inputs? Why or why not? + * How do your collaborators manage data? Which services or processes did your group consider before settling on the current one(s)? + * What (if any) agreements or policies are in place governing how you handle your data and results? For example, if your data relates to people, are there restrictions regarding identifiability of individuals? What restrictions are there on where your data may be stored? + * If there are restrictions on sharing inputs or outputs, how are those restrictions made clear to other researchers (*e.g.* who are evaluating the results that can be publicized)? \ No newline at end of file diff --git a/_project/05_hpc.md b/_project/05_hpc.md new file mode 100644 index 0000000..6034ad5 --- /dev/null +++ b/_project/05_hpc.md @@ -0,0 +1,39 @@ +--- +slug: hpc +title: High Performance Computing +--- +## REQUIRED + +Later today, you will re-present your project. Recall the general feedback on the *purpose* of these: to think of your work from the perspective of how it is *engineered* to acheive your results, and less about the results / analysis per se. Express your project in terms of the flow from start to finish AND identify what element of that you want to work on next week. "Work on" might take many forms - e.g. it could be replacing some element with a library, instrumenting some step to understand how long it takes, documenting code to make it more reuseable, and so on. Be clear about what the *outcome* of that work would be if accomplished AND have a plan that has incremental, small steps. That is, have the work plan start with step that you can think can accomplish in a _very_ short period of time: a morning at most. Assemble your plan out of several such steps. + +Spend _some_ time finalizing that today. Once that's done, please upload your slides to the shared google drive folder. + +However, we do want you to spend some time thinking about the prompts below relative to HPC. Your presentation need not be perfect - it needs to be sufficient to elicit feedback on your plan for the hack-a-thon next week. Hence the emphasis on _some_. + +## Performance of your code + + * Do you know how long it takes for you project to run start to finish? How much memory it uses? How much it reads from / writes to disk? + * Do you know what the relative contribution of each of the sub-steps to that run-time, memory use, read/write? + * If you do know these durations etc, how did you get that information? What tools did you use to measure this? If you don't know, what tools are out there to make this measurement? What might you need to change in your code to make these measurements? + * Measure how long it takes for the operating system to start up and shut down your program + +## Parallel vs Serial + + * Thinking about a pseudocode / flow diagram perspective of your overall project: is there (or could there be) a "repeat X for ..." step? If so, do the steps depend on each other? For example, does the program need the results from step N to accomplish step N+1? Or all those "repeat ..." steps independent? Some mixture of those two? + * If there is a "repeat X for ..." step, is your code currently organized such that those steps can be done independently? I.e., if they are parallelizable, do they each have independent access to input and output space? If serial, does each step produce a "thing" that could be stored and then used in the next step? + * Think about how to organize inputs, sections of code, and outputs in order to run your code in a parallel platform, **sketch this on paper** + * Does it make sense to parallelize some part of your code? Why or why not? + +## Optional Tasks + + * If you answered yes to the last question, start parallelizing your code! + * Investigate some HPC tools. Are any of these relevant to your project? + - tensorflow, [e.g. this quick start tutorial](https://www.tensorflow.org/tutorials/quickstart/beginner) + - hadoop / mapreduce, [e.g. this quick start tutorial](https://hadoop.apache.org/docs/stable/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduceTutorial.html), + - cuda, [for a GPU-based approach](https://cuda-tutorial.readthedocs.io/en/latest/tutorials/tutorial01/) + * Explore HPC / cloud computing service providers: + - [Google Colab](https://colab.research.google.com/) + - [AWS](https://aws.amazon.com/education/awseducate/) + - [Azure](https://azure.microsoft.com/en-us/free/students/) + - [Google Cloud](https://cloud.google.com/edu/students) + - others? \ No newline at end of file diff --git a/_sass/_base.scss b/_sass/_base.scss new file mode 100644 index 0000000..491cbe2 --- /dev/null +++ b/_sass/_base.scss @@ -0,0 +1,211 @@ +/** + * Reset some basic elements + */ +body, h1, h2, h3, h4, h5, h6, +p, blockquote, pre, hr, +dl, dd, ol, ul, figure { + margin: 0; + padding: 0; +} + + + +/** + * Basic styling + */ +body { + font: $base-font-weight #{$base-font-size}/#{$base-line-height} $base-font-family; + color: $text-color; + background-color: $background-color; + -webkit-text-size-adjust: 100%; + -webkit-font-feature-settings: "kern" 1; + -moz-font-feature-settings: "kern" 1; + -o-font-feature-settings: "kern" 1; + font-feature-settings: "kern" 1; + font-kerning: normal; +} + + + +/** + * Set `margin-bottom` to maintain vertical rhythm + */ +h1, h2, h3, h4, h5, h6, +p, blockquote, pre, +ul, ol, dl, figure, hr, +%vertical-rhythm { + margin-bottom: $spacing-unit / 2; +} + + + +/** + * Images + */ +img { + max-width: 100%; + vertical-align: middle; +} + + + +/** + * Figures + */ +figure > img { + display: block; +} + +figcaption { + font-size: $small-font-size; +} + + + +/** + * Lists + */ +ul, ol { + margin-left: $spacing-unit; +} + +li { + > ul, + > ol { + margin-bottom: 0; + } +} + + + +/** + * Headings + */ +h1, h2, h3, h4, h5, h6 { + font-weight: $base-font-weight; +} + + + +/** + * Links + */ +a { + color: $brand-color; + text-decoration: none; + + &:visited { + color: darken($brand-color, 15%); + } + + &:hover { + color: $text-color; + text-decoration: underline; + } +} + + + +/** + * Blockquotes + */ +blockquote { + color: $grey-color; + border-left: 4px solid $grey-color-light; + padding-left: $spacing-unit / 2; + font-size: 18px; + letter-spacing: -1px; + font-style: italic; + + > :last-child { + margin-bottom: 0; + } +} + + + +/** + * Code formatting + */ +pre, +code { + font-size: 15px; + border: 1px solid $grey-color-light; + border-radius: 3px; + background-color: #eef; +} + +code { + padding: 1px 5px; +} + +pre { + padding: 8px 12px; + overflow-x: auto; + + > code { + border: 0; + padding-right: 0; + padding-left: 0; + } +} + + + +/** + * Wrapper + */ +.wrapper { + max-width: $content-width - ($spacing-unit * 2); + margin-right: auto; + margin-left: auto; + padding-right: $spacing-unit; + padding-left: $spacing-unit; + @extend %clearfix; + + @include media-query($on-laptop) { + max-width: $content-width - ($spacing-unit); + padding-right: $spacing-unit / 2; + padding-left: $spacing-unit / 2; + } +} + +iframe { + width: $content-width; + height: $content-width*1109/1440; + frameborder: 0; + allowfullscreen: true; + mozallowfullscreen: true; + webkitallowfullscreen: true; +} + +/** + * Clearfix + */ +%clearfix { + + &:after { + content: ""; + display: table; + clear: both; + } +} + + + +/** + * Icons + */ +.icon { + + > svg { + display: inline-block; + width: 16px; + height: 16px; + vertical-align: middle; + + path { + fill: $grey-color; + } + } +} diff --git a/_sass/_layout.scss b/_sass/_layout.scss new file mode 100644 index 0000000..cef2fed --- /dev/null +++ b/_sass/_layout.scss @@ -0,0 +1,338 @@ + +/** + * Site header + */ +.site-header { + border-top: 5px solid $grey-color-dark; + border-bottom: 1px solid $grey-color-light; + min-height: 56px; + + // Positioning context for the mobile navigation icon + position: relative; +} + +.site-title { + font-size: 26px; + font-weight: 300; + letter-spacing: -1px; + margin-bottom: 0; + float: left; + display: grid; + grid-template-columns: 1fr 4fr; + height:51px; + + &, + &:visited { + color: $grey-color-dark; + } + svg { + grid-column: 1; + grid-row:1; + margin-right: 2px; + height: 50px; + align-self: center; + } + span { + grid-column: 2; + grid-row: 1; + align-self: start; + } + em { + grid-column: 2; + grid-row: 1; + align-self: end; + font-size: small; + } +} + +.site-nav { + float: right; + line-height: 56px; + + .menu-icon { + display: none; + } + + .page-link { + color: $text-color; + line-height: $base-line-height; + + // Gaps between nav items, but not on the last one + &:not(:last-child) { + margin-right: 0px; + @include media-larger($on-palm) { + &::after { + margin-left: 5px; + content: "/"; + display: inline-block; + } + } + } + } + + @include media-query($on-palm) { + position: absolute; + top: 9px; + right: $spacing-unit / 2; + background-color: $background-color; + border: 1px solid $grey-color-light; + border-radius: 5px; + text-align: right; + + .menu-icon { + display: block; + float: right; + width: 36px; + height: 26px; + line-height: 0; + padding-top: 10px; + text-align: center; + + > svg { + width: 18px; + height: 15px; + + path { + fill: $grey-color-dark; + } + } + } + + .trigger { + clear: both; + display: none; + } + + &:hover .trigger { + display: block; + padding-bottom: 5px; + } + + .page-link { + display: block; + padding: 5px 10px; + margin-left: 0px; + } + } +} + + + +/** + * Site footer + */ +.site-footer { + border-top: 1px solid $grey-color-light; + padding: $spacing-unit 0; +} + +.footer-heading { + font-size: 18px; + margin-bottom: $spacing-unit / 2; +} + +.contact-list, +.social-media-list { + list-style: none; + margin-left: 0; +} + +.footer-col-wrapper { + font-size: 15px; + color: $grey-color; + margin-left: -$spacing-unit / 2; + @extend %clearfix; +} + +.footer-col { + float: left; + margin-bottom: $spacing-unit / 2; + padding-left: $spacing-unit / 2; +} + +.footer-col-1 { + width: -webkit-calc(30% - #{$spacing-unit/2}); + width: calc(30% - #{$spacing-unit/2}); +} + +.footer-col-2 { + width: -webkit-calc(70% - #{$spacing-unit/2}); + width: calc(70% - #{$spacing-unit/2}); +} + +// .footer-col-3 { +// width: -webkit-calc(45% - ($spacing-unit / 2)); +// width: calc(45% - ($spacing-unit / 2)); +// } + +.footer-logo { + float: left; + width: -webkit-calc(20% - #{$spacing-unit/2}); + width: calc(20% - #{$spacing-unit/2}); + padding: $spacing-unit/4; + svg { + width:100%; + } + +} + +@include media-query($on-laptop) { + .footer-col-1, + .footer-col-2 { + width: -webkit-calc(50% - #{$spacing-unit/2}); + width: calc(50% - #{$spacing-unit/2}); + } + + .footer-col-3 { + width: -webkit-calc(100% - #{$spacing-unit/2}); + width: calc(100% - #{$spacing-unit/2}); + } +} + +@include media-query($on-palm) { + .footer-col { + float: none; + width: -webkit-calc(100% - #{$spacing-unit/2}); + width: calc(100% - #{$spacing-unit/2}); + } +} + + + +/** + * Page content + */ +.page-content { + padding: $spacing-unit 0; +} + +.page-heading { + font-size: 20px; +} + +.post-list { + margin-left: 0; + list-style: none; + + > li { + margin-bottom: $spacing-unit; + } +} + +.post-meta { + font-size: $small-font-size; + color: $grey-color; +} + +.post-link { + display: block; + font-size: 24px; +} + + + +/** + * Posts + */ +.post-header { + margin-bottom: $spacing-unit; +} + +.post-title { + font-size: 42px; + letter-spacing: -1px; + line-height: 1; + + @include media-query($on-laptop) { + font-size: 36px; + } +} + +.post-content { + margin-bottom: $spacing-unit; + + h2 { + font-size: 32px; + + @include media-query($on-laptop) { + font-size: 28px; + } + } + + h3 { + font-size: 26px; + + @include media-query($on-laptop) { + font-size: 22px; + } + } + + h4 { + font-size: 20px; + + @include media-query($on-laptop) { + font-size: 18px; + } + } + +} + +.people { + ul { + list-style: none; + } + & > ul { + img { + margin: 5px; + margin-bottom: 1em; + border-radius: 50%; + height: 125px; + } + & > li { + clear: left; + } + } + & > ul > li:nth-child(2n) { + clear: right; + img { + float:left; + margin-right: 1em; + } + li { + text-align: left; + } + } + & > ul > li:nth-child(2n+1) { + clear: left; + img { + float:right; + margin-left: 1em; + } + li { + text-align: right; + } + } + /* a:not(:last-child)::after { + content:", " + } */ +} + +.post-content { + &.project { + & > ol, ul > li > ol, ul > li { + margin-bottom: 1em; + } + & > ul { + list-style: none; + } + } +} + +.schedule-table { + width: 100%; + tbody tr { + &:nth-child(odd) { + background-color: lightgrey; + } + } +} diff --git a/_sass/_syntax-highlighting.scss b/_sass/_syntax-highlighting.scss new file mode 100644 index 0000000..8fac597 --- /dev/null +++ b/_sass/_syntax-highlighting.scss @@ -0,0 +1,71 @@ +/** + * Syntax highlighting styles + */ +.highlight { + background: #fff; + @extend %vertical-rhythm; + + .highlighter-rouge & { + background: #eef; + } + + .c { color: #998; font-style: italic } // Comment + .err { color: #a61717; background-color: #e3d2d2 } // Error + .k { font-weight: bold } // Keyword + .o { font-weight: bold } // Operator + .cm { color: #998; font-style: italic } // Comment.Multiline + .cp { color: #999; font-weight: bold } // Comment.Preproc + .c1 { color: #998; font-style: italic } // Comment.Single + .cs { color: #999; font-weight: bold; font-style: italic } // Comment.Special + .gd { color: #000; background-color: #fdd } // Generic.Deleted + .gd .x { color: #000; background-color: #faa } // Generic.Deleted.Specific + .ge { font-style: italic } // Generic.Emph + .gr { color: #a00 } // Generic.Error + .gh { color: #999 } // Generic.Heading + .gi { color: #000; background-color: #dfd } // Generic.Inserted + .gi .x { color: #000; background-color: #afa } // Generic.Inserted.Specific + .go { color: #888 } // Generic.Output + .gp { color: #555 } // Generic.Prompt + .gs { font-weight: bold } // Generic.Strong + .gu { color: #aaa } // Generic.Subheading + .gt { color: #a00 } // Generic.Traceback + .kc { font-weight: bold } // Keyword.Constant + .kd { font-weight: bold } // Keyword.Declaration + .kp { font-weight: bold } // Keyword.Pseudo + .kr { font-weight: bold } // Keyword.Reserved + .kt { color: #458; font-weight: bold } // Keyword.Type + .m { color: #099 } // Literal.Number + .s { color: #d14 } // Literal.String + .na { color: #008080 } // Name.Attribute + .nb { color: #0086B3 } // Name.Builtin + .nc { color: #458; font-weight: bold } // Name.Class + .no { color: #008080 } // Name.Constant + .ni { color: #800080 } // Name.Entity + .ne { color: #900; font-weight: bold } // Name.Exception + .nf { color: #900; font-weight: bold } // Name.Function + .nn { color: #555 } // Name.Namespace + .nt { color: #000080 } // Name.Tag + .nv { color: #008080 } // Name.Variable + .ow { font-weight: bold } // Operator.Word + .w { color: #bbb } // Text.Whitespace + .mf { color: #099 } // Literal.Number.Float + .mh { color: #099 } // Literal.Number.Hex + .mi { color: #099 } // Literal.Number.Integer + .mo { color: #099 } // Literal.Number.Oct + .sb { color: #d14 } // Literal.String.Backtick + .sc { color: #d14 } // Literal.String.Char + .sd { color: #d14 } // Literal.String.Doc + .s2 { color: #d14 } // Literal.String.Double + .se { color: #d14 } // Literal.String.Escape + .sh { color: #d14 } // Literal.String.Heredoc + .si { color: #d14 } // Literal.String.Interpol + .sx { color: #d14 } // Literal.String.Other + .sr { color: #009926 } // Literal.String.Regex + .s1 { color: #d14 } // Literal.String.Single + .ss { color: #990073 } // Literal.String.Symbol + .bp { color: #999 } // Name.Builtin.Pseudo + .vc { color: #008080 } // Name.Variable.Class + .vg { color: #008080 } // Name.Variable.Global + .vi { color: #008080 } // Name.Variable.Instance + .il { color: #099 } // Literal.Number.Integer.Long +} diff --git a/_session/01_design.md b/_session/01_design.md new file mode 100644 index 0000000..dae4039 --- /dev/null +++ b/_session/01_design.md @@ -0,0 +1,6 @@ +--- +slug: design +title: Project Design & Planning +--- + +{% include embedslides.html embedkey = '2PACX-1vSoLuPo2MB90ihF21DJDrSfLn1VJSi_ZTk0XQgJtZnFpWrcEftR7s1rNXla9msXk8ta1KBK5H_ytg8F' linkkey = '1KqBN_6QExMoor7FcqVcNUxbPbK5w-S5UF-WjeVz-8V0' %} \ No newline at end of file diff --git a/_session/02_workspace.md b/_session/02_workspace.md new file mode 100644 index 0000000..8d63a93 --- /dev/null +++ b/_session/02_workspace.md @@ -0,0 +1,16 @@ +--- +slug: workspace +title: Workspace Organization & Tools +--- + +{% include embedslides.html embedkey = '2PACX-1vRrEKDEnmDxBQ1qtYg5xiH9IRNjKeTrdtnoOwZRlQEgWQMdy8qXkXKViDdVcUvL2NOlPQwZ9AAO9D9o' linkkey = '1RuONjswdcDhIMKZtNo21zrOcDjJbFrzKzX6pEC-1rko'%} + +For each of 9 topics, there is some guiding information (e.g., a list of different ways to document code), and some discussion questions. + +* Sometimes they are both squeezed onto the same slide. +* Sometimes there is a discussion prompt first, then suggestions or info later. +* Sometimes, there is some info, then discussion questions. + +There is not enough time to have an extensive discussion of all 9 topics. + +So, pick 3 or 4 topics for in-depth discussions, and move quickly through the other 5 or 6. Perhaps the instructor can ask the students which topics are of most interest. \ No newline at end of file diff --git a/_session/03_reuse.md b/_session/03_reuse.md new file mode 100644 index 0000000..0c3620e --- /dev/null +++ b/_session/03_reuse.md @@ -0,0 +1,133 @@ +--- +slug: reuse +title: Reuse & Reusability +--- + +{% include embedslides.html embedkey = '2PACX-1vQNhI8RlG1rA9hj-wU6C4fi9YZzOeD0OazWf4FHc5OaHDYkcnFEBtASuSg_3lasxKnH6ZFSdX_RzAsp' linkkey = '1rCatD68_9yUCL-wE2gDbXZiivx6BjG9xOT4iTmRyH1c' %} + + diff --git a/_session/04_io.md b/_session/04_io.md new file mode 100644 index 0000000..1a007ce --- /dev/null +++ b/_session/04_io.md @@ -0,0 +1,6 @@ +--- +slug: io +title: Input & Output (IO) +--- + +{% include embedslides.html embedkey = '2PACX-1vQlcTtX1RR90VmkqOu4VINlnt0DqJ-YSsvEJZY8ANJLevF_D_o8NH132dkGi8uq3GPok7HsQfoX-m6x' linkkey = '1O8Oox6j7Exit1Yhbgd_OJdfsauQPPm_zRDQlxZGBa58' %} diff --git a/_session/05_hpc.md b/_session/05_hpc.md new file mode 100644 index 0000000..69322bb --- /dev/null +++ b/_session/05_hpc.md @@ -0,0 +1,36 @@ +--- +slug: hpc +title: High Performance Computing +--- + +[Slides](https://docs.google.com/presentation/d/1_39HFIZZnlEfVV9xLQHlVOGp8k2twCAJ9w0L9Q2e1ps/present). + +1. Computer anatomy + * CPU, RAM, HDD + * Desktop vs. cluster +2. Why do programs run slowly? + * Hardware bottlenecks + * Algorithmic complexity +3. How do you know why a program is slow? + * System utilities: time, top, and profiling tools + * Code/algorithm analysis +4. Parallelizeable problems + * Monte Carlo + * split-apply-combine + * Amdahl's Law + * Race conditions +5. HPC environments + * multithreading + * clusters/supercomputers + * cloud/grid computing + * scheduling jobs +6. Relevant technologies + * Shared vs. distributed memory + * OpenMP, MPI, other language-specific libraries + * Hadoop, MapReduce + +7. GPUs and related terminology + * Single precision computation + * Double precision computation + * Memory management in GPU + * Languages for GPUs - CUDA-C, Python, ... \ No newline at end of file diff --git a/_topic/01_design.md b/_topic/01_design.md new file mode 100644 index 0000000..5dffe3c --- /dev/null +++ b/_topic/01_design.md @@ -0,0 +1,86 @@ +--- +slug: design +title: Project Requirements, Design, & Planning Materials +--- + +SEAMS is about + + - **S***oftware*: useful computer abstractions for transforming inputs into outputs, created by... + - **E***ngineering*: an organized, systematic approach to design and delivery of reliable, flexible, practical, and human-useable systems for... + - **A***pplied*: considering empirical data... + - **M***athematical*: within quantitative, rules-based representations... + - **S***ciences*: that make testable predictions. + +These concepts can guide the way you approach a new research problem--or, put another way, they can help you understand the problem *requirements*, use those to create *design* addessing them, and *plan* the work to execute and validate that design. + +# The Requirements, Design, and Planning Work Loop + +The basis of science is observation, prediction, and experiment. Software might be used in any or all of these steps, and the best practices for those activities translate naturally to any software project. Collecting field data? You need to make unambiguous observations, deal with incomplete measurements, and perhaps even carefully censor certain observations. These translate directly into implementation issues for your project: how to represent measurements (with or without units? standardizing categorical data?), differentiate between *nothing observed* and *not observed*, and transform raw data into curated, ready-to-analyze data. + +A deliberate approach to **Design** is one way researchers can ensure that their work meets the high standards of Science. Taking the time to make a design does not directly write the code to solve your problem, and as such people often think "Why bother?" For exploratory work, that approach can be fine. But much like a scientist cannot undertake experimental, publishable work without establishing a protocol (and in the case of clinical trials, this is a *legal* matter), approaching a serious programming project without laying it out first will doom the result. + +For this topic, we recommend you think of loop of activities: determining *requirements*, setting a *design* that will verifiably satisy those requirements, and *planning* on how to execute that design. + +## Requirements + +There are a variety of good formal descriptive approaches used for thinking about requirements. None of them are perfect for every combination of people and project! However, usually all of them can provide some insight into thinking about your problem. + +In general, developing requirements is about having *sufficient* constraints (1) to start working on your problem and, later, (2) to tell if you have actually solved your problem. Generally, you should start without having (2) completely finished (at least, for a completely new project - extending a well-established project is another matter), but you aren't finished until (2) is complete. + +For both (1) and (2), you can often identify constraints by posing questions and thinking about their answers. The mneumonic **5WH** is a good general set of questions to start with: + + - *What*: what are the input(s)? the analysis? the output(s)? + - *Why*: why do the work? to answer a specific question now? a generic question when data becomes available? to simplify or standardize future work? + - *Who*: who is going to provide input? use the software? see the outputs? + - *Where*: where does your program run? a personal computer, a supercomputer, over the web, ...? + - *When*: when does the program run? once, so you can publish results? whenever new data becomes available? + - *How*: how does the software provide the needed capabilities? in a particular language? using a particular library? + +These questions can be initially answered somewhat loosely--e.g., the input is a csv file--and increasingly refined as you develop the project and learn more about the detailed requirements--e.g., the input is a filename, provided via command line argument, which identifies a csv file which is semi-colon delimited. + +### Requirements References + + - [Wikipedia: Software Requirements](https://en.wikipedia.org/wiki/Software_requirements), and most particularly the [specification section](https://en.wikipedia.org/wiki/Software_requirements_specification). There's some business jargon, but the high level concepts (e.g., user stories) may be applicable to your project. + - Assorted other requirements related items: [here](https://www.geeksforgeeks.org/software-engineering-requirements-engineering-process/), [here](http://www.inf.ed.ac.uk/teaching/courses/cs2/LectureNotes/CS2Ah/SoftEng/se02.pdf), [and here (though this one has annoying pop-ups)](https://www.guru99.com/learn-software-requirements-analysis-with-case-study.html) + +As always: if you find an interesting / useful link or book, please feel free to suggest it to the site by forking, editing this file, and requesting a merge! + +## Design + +With a starting set of requirements, you can record a design for how information will flow (and is transformed) from input(s) to output(s). You can write this flow down using something between prose (often called plain or natural language) and pseudo-code, but the key here is communication: you are providing a document for other developers (including future you!), users (again, future you!), and scientists reviewing your work (still including future you!) to think about what your software does. This high level description should be roughly consistent with what you might put in the main text of a scientific publication for a "Materials & Methods" section. + +Circling back to requirements, you should have a clear idea which steps are associated with which needs. If there's a big imbalance in your requirements--most link to a single step, say, then perhaps you need to revisit your steps (though you may just have a high level of details in part of your requirements and a lot of work to do on the rest). Alternatively, if a particular requirement is associated with too many steps, you probably don't have enough detail in the requirement or your steps aren't dividing up your problem cleanly. This approach is more than just shuffling around words--taking this approach will help you size your code into intellectually and practically digestible chunks. + +Your architecture can be used as a skeleton for your project. For example, if you identify seven high level steps, you can probably organize your code into seven high level pieces (e.g., seven scripts or folders collecting related scripts, or seven top level `make` targets). If you try to organize that way, and determine it makes more sense to have, say, four of those things (whatever the right instantiation is), then perhaps your high level process is only four steps. These steps indicate minimal boundaries where you might want to test outputs, or store intermediate results. They represent chunks that might be reusable (or largely replaceable with external libraries). + +Finally, this approach to designing your project is iterative. Obviously, you can refine your high level steps, but also you can dig inside each step. While your initial steps correspond to high level processes, each refinement corresponds to lower level detail. There should be at least a few passes at this refinement between the highest level description of your approach and the level which is quite nearly actual code. + +### Design References + + - [Wikihow: Pseudocode](https://www.wikihow.com/Write-Pseudocode) + - [Stackoverflow: Coding 102](https://stackoverflow.blog/2023/02/13/coding-102-writing-code-other-people-can-read/) + - [Latex Packages for Pseudocode](https://ctan.org/topic/pseudocode) - checkout package documentation for examples of various styles + - [Wikipedia: Flow Diagrams (check out the for loop)](https://en.wikipedia.org/wiki/Flowchart) + - [(Youtube) Flowcharts and Pseudocode](https://www.youtube.com/watch?v=Yq1OPs5hCt0) + - [Smartdraw (commercial product)](https://www.smartdraw.com/flowchart/flowchart-programming.htm) + - the [Wikipedia page](https://en.wikipedia.org/wiki/Software_architecture) is a thorough overview, though a bit technical. Start with the History section. + - [Some](https://refactoring.guru/design-patterns) [introductory pages](https://www.tutorialspoint.com/design_pattern/index.htm) on [design patterns](https://www.cs.cmu.edu/~charlie/courses/15-214/2016-spring/slides/24%20-%20All%20the%20GoF%20Patterns.pdf). + +# Planning + +With a project design in mind, researchers can make a plan to accomplish that work. Important scientific work is increasingly collaborative, and modern communication technology enables those collaborations to occur across continents. Similar technology makes unprecedented amounts of computational resources available for research. + +However, effective use of these advantages requires careful planning. Software development companies will often adopt formal planning and tracking processes once they reach sufficient size and project complexity. At SEAMS, we are not covering any of those formal processes directly, but rather focusing on the more fundamental concepts such approaches are intended to address. + +Part of planning is writing down requirements and architecture. Next is ordering the implementation, scheduling, and if the work is collaborative, figuring out who is covering what part of the project. When executing your design, plan to implement a piece at a time, and to use that piece to produce results. That is, implement the smallest practical bit, verify the code behaves as you intend, and then move on to the next piece. This process of isolation also creates an organization where multiple people can attend to different pieces. + +# Other References + + - [Wikipedia: Software Design](https://en.wikipedia.org/wiki/Software_design); ignore the arcane vocabulary, and focus on the high level concepts + - [An introduction to software testing](http://agile.csc.ncsu.edu/SEMaterials/BlackBox.pdf) + - [A general guide to testing in Python](http://docs.python-guide.org/en/latest/writing/tests/) + - [A guide to `unittest` (PyUnit)](http://www.drdobbs.com/testing/unit-testing-with-python/240165163) + - [...and another](http://pythontesting.net/framework/unittest/unittest-introduction/) + - [using R package testthat](http://journal.r-project.org/archive/2011-1/RJournal_2011-1_Wickham.pdf) + - [Tests for randomness](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.156.7149&rep=rep1&type=pdf) + - [Thinking a bit about what testing means.](http://www.nytimes.com/interactive/2015/07/03/upshot/a-quick-puzzle-to-test-your-problem-solving.html) \ No newline at end of file diff --git a/_topic/02_workspace.md b/_topic/02_workspace.md new file mode 100644 index 0000000..aaec9d9 --- /dev/null +++ b/_topic/02_workspace.md @@ -0,0 +1,212 @@ +--- +slug: workspace +title: Workspace Organization & Tools +--- +# Overview: guiding principles + +Our goal as scientists is to create useful knowledge (*useful* may be defined on a very long time scale). Knowledge doesn't exist if people don't have access to it, and it's not useful if they can't engage with it. + +## Think in Terms of the **Product** + +We want "software" (*e.g.*, the combination of scripts, analysis code, data management, reference management, external tools devoted to addressing a particular research question or area) that is: + + - easy to use correctly + - easy to verify (*i.e.*, does what intends) and validate (*i.e.*, clear expectation of output for given inputs) + - easy to know when using incorrectly, and what to change to use correctly + - easy to understand, both as a whole and individual parts + - plausible to deploy in other settings (*e.g.*, distributed computation, GUI tool for non-technical users) + - generalizable (*e.g.*, different dataset / context) + +## Think in Terms of the **Process** + +Organization should support: + + - shifting data (new data, updates to existing data, changes to schema) + - effective collaboration with people in different roles (*e.g.*, theoreticians, modelers, field scientists) + - portability + - publication (results *as well as recipe*) + - subsequent extension + +## Resources + +* [DataONE primer on data management](https://www.dataone.org/sites/all/documents/DataONE_BP_Primer_020212.pdf) (PDF) +* Wilson, et al. [Best Practices for Scientific Computing](https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.1001745) +* [Ten Simple Rules for Reproducible Computational Research](http://dx.doi.org/10.1371/journal.pcbi.1003285) + +# Topics + +## Plan to manage your resources + +Stages and activities in the data life-cycle +* Storage and backup. Safeguard against accidental loss or corruption. +* Organization. see below. +* File encodings +* Describe and document. see below. +* Sharing and re-use +* Preservation + +**Resources** + - [FAIR data principles](https://www.force11.org/group/fairgroup/fairprinciples) + - [DataONE primer on data management](https://www.dataone.org/sites/all/documents/DataONE_BP_Primer_020212.pdf) (PDF) + - [Introduction to Open Science: Why data versioning and data care practices are key for science and social science.](http://blogs.lse.ac.uk/impactofsocialsciences/2015/02/09/data-versioning-open-science/) + - [Data Management Discussion](http://mariovalle.name/sdm/scientific-data-management.html) + + + + + - [UK Data Archive](http://www.data-archive.ac.uk/media/2894/managingsharing.pdf) - good general read, but certain specific sections pertinent to how to organize / save yours + +## Using version Control + +**Resources** + - [SO: Why Should I Use Version Control?](http://stackoverflow.com/questions/1408450/why-should-i-use-version-control) and [Academia SE: Why Use VC for Writing a Paper?](http://academia.stackexchange.com/questions/5277/why-use-version-control-systems-for-writing-a-paper) + - [Biomed Central Blog](http://blogs.biomedcentral.com/bmcblog/2013/02/28/version-control-for-scientific-research/) - several links to other publications on value of version control in science + - Git Tutorials: + * [with GitHub](https://try.github.com/) + * [visualization](http://pcottle.github.io/learnGitBranching/) + * [undoing](https://github.com/blog/2019-how-to-undo-almost-anything-with-git) + * [writing good commit messages](http://chris.beams.io/posts/git-commit/) + + +Protocol questions +* what goes under version control, and what doesn't +* branching protocol +* gitflow and other patterns + +## Organizing project resources + +Your future self is probably the top stakeholder. Think about designing products that will be distributed, either to your future self or to others. + +* If you can't keep everything in one directory, maintain an up-to-date Project Map document that points to all resources. Think of your project as a network of resources. It needs to have a clearly identifiable **root** from which you can reach everything else-- no orphans. +* Use a directory hierarchy for major dimensions (e.g., studies, data types), and file names for minor dimensions (e.g., replicates, dates). + * Use "Archive" subdirs to keep your project tidy (leave them out of a distributed package) + * Use “README.txt” files to explain major directories + * Apply a consistent model, e.g., CamelCase.txt, kebab-case.txt, snake_case.txt. + * Make names from letters, numbers, and dot (.), dash (-) or underscore (_). Other characters can hinder automated processing. + * Be concise, e.g., "data-table" is redundant in ir-expt01-sample028-data-table.csv. + * Make sure dates and numbers sort as desired. Use ISO 8601 (YYYYMMDD). Pad counting numbers with leading zeros: 2 sorts after 12, but 02 sorts before 12. +* Create a file list (manifest) and refer to it in your top-level README file + * `ls -AFR1 path_to_my_dir > MANIFEST` + * `tar -cv path_to_my_dir 2>&1 >/dev/null | sort | sed 's/^a //' > MANIFEST` + +**Resources** +* Dryad's instructions to [Name files and directories in a consistent and descriptive manner](https://datadryad.org/pages/reusabilityBestPractices#filenames) +* Dryad's instructions to [Organize files in a logical schemaf](https://datadryad.org/pages/reusabilityBestPractices#organize) + +## Issue tracking + +GitHub.com and GitLab.com both offer built-in issue tracking systems. + +However, issue tracking systems are not just for software. Customer service departments use them to record complaints and other issues, and to track how those issues are addressed. Many people use issue trackers such as Trello as personal productivity tools. + +Some of the key concepts are +* opening and closing. An issue or ticket is "open" until it is resolved, then it is "closed". Often there is a flow for tickets with 4 or 5 stages + * backlog. low priority or unprioritized issues, e.g., something we might do some day + * ready. issues prioritized for action + * in progress. a developer is working on this + * needs review. developer is done, now look at results and decide whether to close or put back in "ready" + * closed. this issue is done. open new tickets for any separate tasks provoked by this issue. +* assignment. Issues can be assigned to one or more persons. A programmer who completes work on a ticket may assign it to a second person for review. +* monitoring and notification. Action on issues can be monitored with automatic notification. At the level of the whole project, you can monitor how many issues are closed each month. +* tagging and grouping. Issues can be tagged ("bug", "feature request") and grouped into sets corresponding to milestones or sprints. +* prioritization. A team may get together regularly to review open tickets and prioritize them for action. + +**Resources** +* Wikipedia [issue tracking system](https://en.wikipedia.org/wiki/Issue_tracking_system) +* [Comparison of issue-tracking systems](https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems) + +## Using tests + +What do you test? Focus first on functional requirements. This applies both to low-level testing and to high-level testing. Your software (and its functions or methods) is supposed to generate some useful output from valid inputs. Make sure it does. Then you can start testing for other things, like how well it handles exceptions such as invalid inputs. + +Some concepts +* "regression testing" means checking that the software still does what it did previously +* unit tests focus on individual functions or methods +* integration tests depend on multiple functions or methods working together + +**Resources** +* [20 practical testing tips](https://www.softwaretestinghelp.com/practical-software-testing-tips-to-test-any-application/) +* wikipedia on [software testing](https://en.wikipedia.org/wiki/Software_testing) +* R unit-testing library [testthat](https://testthat.r-lib.org/) +* Python [unittest](https://docs.python.org/3/library/unittest.html) + +## Packaging resources for distribution + +**Resources** +* [General Discussion for R Packages](http://r-pkgs.had.co.nz/) +* [Python Project Template Guide](http://learnpythonthehardway.org/book/ex46.html) - challenge: write a bash script to automate this approach +* [...or try any of several pre-packaged options](https://www.google.com/search?q=python%20package%20template) + +## Documenting code + +**Resources** +* [a beginner's guide to writing docs](https://www.writethedocs.org/guide/writing/beginners-guide-to-docs/) +* [Sphinx](http://www.sphinx-doc.org/en/master/) +* in-line documentation + * [Doxygen](https://en.wikipedia.org/wiki/Doxygen) (for C, C++, Java, Python, some other languages) + * Python in-line [DocStrings explanation](https://www.electricmonk.nl/log/2008/06/22/why-python-rocks-i-inline-documentation/ +) + * [Writing documentation with ROxygen2](http://kbroman.org/pkg_primer/pages/docs.html) (R in-line documentation) + * Perl's [POD (plain old documentation)](https://perldoc.perl.org/perlpod.html). Always remember with POD that you have to put blank lines before and after each command. +* why [writing better code reduces the need for commenting](https://medium.com/@andrewgoldis/how-to-document-source-code-responsibly-2b2f303aa525) + +## IDEs and other tools + + - [What is an IDE](http://en.wikipedia.org/wiki/Integrated_development_environment) and [why use one](http://programmers.stackexchange.com/questions/20950/what-justifies-the-use-of-an-ide-versus-a-standard-editor) [(or not)](http://blog.bittersweetryan.com/2012/02/great-ide-vs-text-editor-debate-why-i.html)? + - [Broad Comparison of IDE](http://en.wikipedia.org/wiki/Comparison_of_integrated_development_environments) - what seems to be important? + - [RStudio IDE Project](https://support.rstudio.com/hc/en-us/articles/200526207-Using-Projects) + - [PyCharm IDE Project](https://www.jetbrains.com/pycharm/help/project.html) + +## Collaboration technology and protocols + +How are you going to share work? Communicate? Keep records of decisions? Track progress on goals? Choose a set of assistive technologies for sharing, and develop protocols for using them with your team. + +### Technologies + +Decide what **types** of communication and collaboration technology facilitate the success of your project. Choose (ideally) just one tool of each type. + +1. communication and collaboration technology types + * real-time communication by phone, email, or chat + * virtual meetings (Skype, Hangout, Zoom, etc) + * comment threads on tickets in your issue tracker +1. file-sharing + * version control + * DropBox, Drive, etc +1. document-sharing and collaborative editing + * Drive docs, etherpad + +How much can you do with one platform? For instance, maintain code and issues in GitHub, maintain planning docs on GitHub as well, add gitter for chat, add Waffle for multi-repo project tracker, Jekyll for CI. + +### Protocols + +1. Agree on which technologies are used for which things. + * What goes into version control in a shared repo, and what goes in document sharing? + * Public vs. private is a big issue here. You may have a public code repo, but you need a private channel to discuss sensitive project issues, and a private file-sharing space for things like manuscripts in progress. Do you want to keep planning documents private? Do you want a private communication channel? + * Which kinds of plans are discussed in a public chatroom, and which are reserved for private channels +1. Agree on how to use a technology + * shared editing. Wikipedia style, or is one person the lead author or owner? + + + + + + + diff --git a/_topic/03_reuse.md b/_topic/03_reuse.md new file mode 100644 index 0000000..8e48535 --- /dev/null +++ b/_topic/03_reuse.md @@ -0,0 +1,57 @@ +--- +slug: reuse +title: Reuse & Reusability +--- +# Reference materials and information on reuse and accessibility + +## What makes code re-useable? + +* Wilson, et al. [Best Practices for Scientific Computing](https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.1001745) +* [Ten Simple Rules for Reproducible Computational Research](http://dx.doi.org/10.1371/journal.pcbi.1003285) +* [FAIR data principles](https://www.force11.org/group/fairgroup/fairprinciples) +* A nice guide to [structuring your python repo](https://docs.python-guide.org/writing/structure/) + +## Packages + +### Package managers + +Package managers automate the process of installing pre-built packages in a way that fits your system. When a package manager is working ideally on your system, it knows which packages are installed already, and their versions, and knows how to follow the instructions for new packages so as to identify dependencies, generate a workflow, and execute the workflow to build and install the package and its requirements. + +The first rule of package managers is to pick one and use that all the time. Don't install packages manually or use other managers, which can create a mess. Unfortunately, it is not always possible to use only one package manager. + +* Wikipedia's list of [package management systems](https://en.wikipedia.org/wiki/List_of_software_package_management_systems) + +### Package development + +Someone has to make those nice packages. Maybe that's you. Ideally your package is amenable to automated installation because it follows the conventions expected by package installers. Package generation tools exist for R, Python and other languages. + +Package generation tools +* [devtools](https://cran.r-project.org/web/packages/devtools/index.html) for R packages +* [quickie intro to devtools](https://www.rstudio.com/products/rpackages/devtools/) +* introduction to using Python's [setuptools](https://packaging.python.org/tutorials/packaging-projects/) + +There are also best practices for structuring your repositories. +* [General discussion of best practices for R Packages](http://r-pkgs.had.co.nz/) +* [Python Project Template Guide](http://learnpythonthehardway.org/book/ex46.html) +* A nice guide to [structuring your python repo](https://docs.python-guide.org/writing/structure/) +see the workspace reference for hadley wickham guide to R packages. +* [...or search for templates online](https://www.google.com/search?q=python%20package%20template) + +These are best practices for data repositories, but I find them useful for code as well +* Dryad's instructions to [Name files and directories in a consistent and descriptive manner](https://datadryad.org/pages/reusabilityBestPractices#filenames) +* Dryad's instructions to [Organize files in a logical schemaf](https://datadryad.org/pages/reusabilityBestPractices#organize) + +## Standing up an accessible service + +Sometimes the best way to make your work accessible to others is to provide the code. In other cases, it is better to provide functionality directly through a web application, a web service, or other means. + +* Python's [web2py](http://www.web2py.com/) +* R's [rshiny](https://www.rstudio.com/products/shiny-2/) + +## cross-platform compilation + +* [Brian’s 10 Rules for how to write cross-platform code](https://www.backblaze.com/blog/10-rules-for-how-to-write-cross-platform-code/) + +## Licensing + +* [choosing a license](https://www.cio.com/article/2382115/open-source-tools/how-to-choose-the-best-license-for-your-open-source-software-project.html) \ No newline at end of file diff --git a/_topic/04_io.md b/_topic/04_io.md new file mode 100644 index 0000000..c8762a9 --- /dev/null +++ b/_topic/04_io.md @@ -0,0 +1,50 @@ +--- +slug: io +title: Input & Output (IO) +--- + +## Parse, search and manipulated formatted text like HTML and XML +http://www.crummy.com/software/BeautifulSoup/ + +## Web scraping with Beautiful Soup +http://www.pythonforbeginners.com/beautifulsoup/web-scraping-with-beautifulsoup + +## How can I write/edit a csv file based on conditions +http://www.reddit.com/r/learnpython/comments/34g4yo/how_can_i_writeedit_a_csv_file_based_on_conditions/ + +## How do I handle passwords? +http://www.reddit.com/r/learnpython/comments/32kinl/how_do_i_handle_passwords/ + +## Reading and Writing Files +http://automatetheboringstuff.com/chapter8/ + +## Organizing Files +http://automatetheboringstuff.com/chapter9/ + +## Web Scraping +http://automatetheboringstuff.com/chapter11/ + +## Working with Excel Spreadsheets +http://automatetheboringstuff.com/chapter12/ + +## Working with PDF and Word Documents +http://automatetheboringstuff.com/chapter13/ + +## Working with CSV Files and JSON Data +http://automatetheboringstuff.com/chapter14/ + +## Sending Email and Text Messages +http://automatetheboringstuff.com/chapter16/ + +## What databases are and what they are used for ? +* http://people.scs.carleton.ca/~achan/teaching/comp1001/notes/COMP1001-06.pdf +* https://dzone.com/articles/what-are-databases-used-for + +## Data Analysis and format performance +* http://statmath.wu.ac.at/courses/data-analysis/itdtHTML/node56.html#SECTION001154000000000000000 +* https://www.svds.com/how-to-choose-a-data-format/ +* https://afit-r.github.io/tidyr +* https://cran.r-project.org/web/packages/msgpack/vignettes/comparison.html#r-serialization + +## Data Storage +* http://statmath.wu.ac.at/courses/data-analysis/itdtHTML/node51.html diff --git a/_topic/05_hpc.md b/_topic/05_hpc.md new file mode 100644 index 0000000..b821798 --- /dev/null +++ b/_topic/05_hpc.md @@ -0,0 +1,35 @@ +--- +slug: hpc +title: High Performance Computing +--- + +A working understanding of the physical parts of a computer is important for making decisions about how to make code faster. +- [Here's a basic overview of the parts of a modern desktop computer](http://sites.jmu.edu/103oconnor-16/introduction-to-basic-computer-components-and-functions/) If you've never built a computer, this might be helpful. +- [How are supercomputers different?](https://en.wikipedia.org/wiki/Supercomputer_architecture) +- [What is cache, and why does it speed things up?](https://softwareengineering.stackexchange.com/questions/234253/why-is-cpu-cache-memory-so-fast) +- [How big should a page file/swap partition be?](https://www.howtogeek.com/196238/how-big-should-your-page-file-or-swap-partition-be/) + +Why is my code slow? +- [Profilers can help you identify code bottlenecks](https://stackify.com/what-is-code-profiling/) +- [One developer's story of how he used unit testing concepts to benchmark his code](https://bruun.co/2012/02/07/easy-cpp-benchmarking) +- [Big-O notation and algorithmic complexity--aka, maybe your algorithm is the problem](https://www.cs.cmu.edu/~adamchik/15-121/lectures/Algorithmic%20Complexity/complexity.html) +- [A proof of Amdahl's Law, which predicts how much a program can be sped up when parallelized](https://www.geeksforgeeks.org/computer-organization-amdahls-law-and-its-proof/) + +So you want to parallelize . . . +- [A phenomenal introduction to parallel computing](https://computing.llnl.gov/tutorials/parallel_comp/) +- [An intuitive explanation of race conditions: how many people does it take to turn off a light?](https://searchstorage.techtarget.com/definition/race-condition) +- [Multithreading is an approach to parallelization, but doesn't always result in parallelization](https://stackoverflow.com/questions/806499/threading-vs-parallelism-how-do-they-differ) +- [An overview of cloud computing (not a how-to)](https://www.dialogic.com/~/media/products/docs/whitepapers/12023-cloud-computing-wp.pdf) +- [MPI: tutorials for how to parallelize in hardcore mode, generally for compiled languages](http://mpitutorial.com/tutorials/) +- Map-Reduce, Spread-Gather - some sort of link to embarassingly parallel problem framings +- [Difference between CPU and GPU computing](https://medium.com/altumea/gpu-vs-cpu-computing-what-to-choose-a9788a2370c4) +- [GPU computing, it's strengths and limitations](http://lorenabarba.com/gpuatbu/Program_files/Cruz_gpuComputing09.pdf) + + \ No newline at end of file diff --git a/_warmup/00_opening.md b/_warmup/00_opening.md new file mode 100644 index 0000000..5b8c517 --- /dev/null +++ b/_warmup/00_opening.md @@ -0,0 +1,14 @@ +--- +slug: opening +title: Opening Remarks +--- + +Welcome, Akwaaba! + +Opening remarks from Prof. Francis Allotey, President of AIMS-Ghana. + +Introduction of Lecturers, Program Goals, Dr. Wilfred Ndifon + +How CAMS Supports the AIMS Mission, Dr. Prince Osei, AIMS Ghana Academic Director (outgoing) + +How CAMS can *better* support the AIMS Mission, Prof. Emmanuel Essel, AIMS Ghana Academic Director (outgoing) diff --git a/_warmup/01_overview.md b/_warmup/01_overview.md new file mode 100644 index 0000000..373bfe7 --- /dev/null +++ b/_warmup/01_overview.md @@ -0,0 +1,20 @@ +--- +slug: overview +title: Overview +--- + +Why are *you* here? + +## Project Focus + +*CAMS* is about skills for accomplishing projects. Part of research is innovation, inspiration, insight, and so on. But all the great ideas are for naught, if they are not realized in practice. + +So when we discuss ideas, we also immediately try them: first in practice, then on work that interests us. To that end, we asked participants to submit proposed projects and we also selected some projects from our own work. Each of these is real work, that could be used by other people some day - as published research, as an open-access tool for policymakers, as a library for small business owners. + +## General Reference + + - [Software Carpentry](http://software-carpentry.org/lessons.html) + - [R Packages Ebook](http://r-pkgs.had.co.nz/) + - [Many Language Tutorials](http://hackr.io/) + - [Description of CompSci concepts in (Western) everyday terms](http://carlcheo.com/compsci) + - [Motivational Video](https://www.youtube.com/watch?v=mvK0UzFNw1Q) diff --git a/_warmup/02_git.md b/_warmup/02_git.md new file mode 100644 index 0000000..0228a07 --- /dev/null +++ b/_warmup/02_git.md @@ -0,0 +1,6 @@ +--- +slug: git +title: Git Tutorial +--- + +First, make sure you have an account on GitHub. Then, work through this [git visual tutorial](http://pcottle.github.io/learnGitBranching/). diff --git a/_warmup/03_puzzling.md b/_warmup/03_puzzling.md new file mode 100644 index 0000000..09ea33a --- /dev/null +++ b/_warmup/03_puzzling.md @@ -0,0 +1,21 @@ +--- +slug: puzzling +title: Puzzling +--- + +[Stackoverflow](http://stackoverflow.com/) is a great site for finding answers to coding questions (and for asking new ones if you can't find what you seek). + +But! + +There is a whole network of *Stackexchange* sites, some of which concern puzzles (amongst other delightfully nerdy subjects). + +For today's warmup, you should visit two of them: [Puzzling](http://puzzling.stackexchange.com/) and [Codegolf](http://codegolf.stackexchange.com/). + +Try at least the following problems (without looking at the answers already submitted!): + + - [Math symbol Tricks](http://puzzling.stackexchange.com/questions/16796/math-do-you-enjoy-it-really) + - [Pi Day](http://puzzling.stackexchange.com/questions/10972/pi-day-puzzle-one-to-twenty) + - [88 pies](http://puzzling.stackexchange.com/questions/8662/a-puzzle-about-baking-88-pies) + - [Leap Seconds!](http://codegolf.stackexchange.com/questions/52452/leap-for-leap-seconds) + - [Milk Expiration](http://codegolf.stackexchange.com/questions/33033/has-my-milk-expired) + - [Chinese Zodiac](http://codegolf.stackexchange.com/questions/19041/calculate-chinese-zodiac-sign) diff --git a/_warmup/04_test.md b/_warmup/04_test.md new file mode 100644 index 0000000..914b857 --- /dev/null +++ b/_warmup/04_test.md @@ -0,0 +1,29 @@ +--- +slug: testing +title: Testing an Instructor +--- +## Warmup Exercise for Software Testing + +The goal of this exercise is to successfully "program" a blindfolded person to drop a plastic bottle into a metal basket. + +Nicky will exit the room in order to give the team an opportunity to write (and test!) a set of instructions for dropping his bottle into the basket. After each trial, Carl will reset the location of the basket, as well as obstacles (*i.e.* chairs). + +During the trial, Ethan will read each line of instruction, exactly as written, out loud. Nicky will execute the instruction as he understands them, and then say "COMPLETE" (or, you know, something like that) when he believes he has carried out the line of code. Then Ethan will move on to the next line, and the process repeats. + +Some example instructions: + + - for loops: walk exactly n steps forward, or turn exactly n degrees (tough to estimate) + - while loops: walk until you bump into something that feels like x, OR reach out your right hand and turn either up or down (think: that rule from physics) until you feel something that feels like x, + - conditionals: if you reach and feel x directly between your two feet, or directly in front of you, or directly behind you, do [another admissible instruction] else do [another admissible instruction] + - Lift up your hand directly in front of you, bending at the elbow, and drop the bottle + +In addition, before Nicky leaves the room to allow teams to prepare, each team may test a blindfolded Nicky on how he interprets instructions. + +Other rules: + - teams may not interact with Nicky, physically or verbally + - There may be no more than 24 instructions + - You may get more creative on instructions than the examples listed above, but use good judgment. If something seems even a bit like cheating, don't do it + +After a failed attempt the failing team must submit a "volunteer," and the game will run again, except with "volunteer" replacing "Nicky" in all lines above. After a successful attempt, "Nicky" above may be replaced with a willing faculty member of the winning teams choosing (which might mean Nicky again), or a volunteer from another team of the winning team's choice. + +Recall that every time the game is played, Carl resets the game's parameters. diff --git a/_warmup/10_sql.md b/_warmup/10_sql.md new file mode 100644 index 0000000..a09aa48 --- /dev/null +++ b/_warmup/10_sql.md @@ -0,0 +1,38 @@ +--- +slug: sql +title: SQLite Practice +--- + +## The Assignment: +Create an SQLite database to hold information about your classmates and the projects they're working on. + +A few details that will make sense later: Use two tables called *students* and *projects*. *students* +should have fields for first/given name, last/family name, github username, and an id number for their +project. *projects* should have a unique id number that you assign, a title, and a main programming +language. Include, at a minimum, the complete information for at least two projects in the class. + +## The Background: +An SQLite database is a single file on your computer that provides a flexible way of storing *structured* +data. Structured, in this context, means you can describe rules for how different types of information +relate and the database will enforce them. (For this reason, these kinds of databases are called *relational* +databases.) For example, you can specify that each student has one project, +each project has at least one student, and students and projects must both have names. Once you have a +database you can *insert* new data, *update* existing data, *alter* the existing structure of the database, +and *select* information to retrieve from the database. One of the nice things about using a database for +retrieving data is that you can use rules to control what information you get (e.g., I want all projects +that are using Python) and you can do operations on them too (e.g., I want a list of all projects with a +*count* of how many students are working on each one). + +## The Approach: + + 1. Work through the exercises [in this tutorial](http://www.thegeekstuff.com/2012/09/sqlite-command-examples/) +at least until you think you know how to approach the assignment specified above. + 2. One of the great things about SQLite is that you can work with it on the command line as in that tutorial, +or you can work with it programmatically, meaning you can write a program in a large number of different +languages that will do all of the creating, inserting, and selecting. The SQLite file will still exist on +the hard drive if you want to inspect your data yourself, but that's not strictly necessary. + + Find a guide or tutorial that explains how to work with SQLite in your preferred programming language. Here are a couple +options we found [for python](http://www.pythoncentral.io/series/python-sqlite-database-tutorial/) and +[for R](http://rstudio-pubs-static.s3.amazonaws.com/8753_a57d3950027541a590c9b40a045accbf.html). Feel free to look +around for others. diff --git a/_warmup/11_abm.md b/_warmup/11_abm.md new file mode 100644 index 0000000..1aad1a6 --- /dev/null +++ b/_warmup/11_abm.md @@ -0,0 +1,18 @@ +--- +slug: abm +title: Agent Based Models +--- + +Read about [Agent Based Models](http://www.palgrave-journals.com/jos/journal/v4/n3/full/jos20103a.html). + +[This](https://www.binpress.com/tutorial/introduction-to-agentbased-models-an-implementation-of-schelling-model-in-python/144) explains the Python code for an Agent Based Model of racial segregation in New York City. Read it carefully, and try to understand what the code does. Your goal this morning is to understand the code completely and get it running on your laptop. To guide your understanding, answer these questions about the model: + + 1. What specific problem is solved by the model? What specific questions does the model answer? What value does agent-based modeling bring to the problem that other modeling approaches cannot bring? + 2. What are the agents in the model? Who are the decision makers in the system? What are the entities that have behaviors? What data on agents are simply descriptive (static attributes)? What agent attributes would be calculated endogenously by the model and updated in the agents (dynamic attributes)? + 3. What is the agents’ environment? How do the agents interact with the environment? Is an agent's mobility through space an important consideration? + 4. What agent behaviors are of interest? What decisions do the agents make? What behaviors are being acted upon? What actions are being taken by the agents? + 5. How do the agents interact with each other? With the environment? How expansive or focused are agent interactions? + 6. Where might the data come from, especially on agent behaviors, for such a model? + 7. How might you validate the model, especially the agent behaviors? + +Name your file SchellingModel.py. If you don't understand what a line of code does, use google or encode a test to figure it out. Then comment the code with what you've learned. diff --git a/_warmup/12_stub.md b/_warmup/12_stub.md new file mode 100644 index 0000000..415a77a --- /dev/null +++ b/_warmup/12_stub.md @@ -0,0 +1,6 @@ +--- +slug: stub +title: Stub +--- + +WARMUP STUB diff --git a/_warmup/13_lists.md b/_warmup/13_lists.md new file mode 100644 index 0000000..1a98cb4 --- /dev/null +++ b/_warmup/13_lists.md @@ -0,0 +1,14 @@ +--- +slug: list +title: List Implementations +--- + +For our last warmum we would like you to implement, in order as you finish them, the following three data structures in Python: + +- Stack (Find specs [here](http://interactivepython.org/runestone/static/pythonds/BasicDS/TheStackAbstractDataType.html)) +- Queue (Find specs [here](http://interactivepython.org/runestone/static/pythonds/BasicDS/TheQueueAbstractDataType.html)) +- Deque (Find specs [here](http://interactivepython.org/runestone/static/pythonds/BasicDS/TheDequeAbstractDataType.html)) + +By implement, we mean you should create classes in python for each of the above data types, with all of the methods described in their specs pages. So, for example, the Stack class should have a method called "push," which takes in an object and appends it to the stack, and a method called "pop" which returns the most recently pushed object and removes it from the stack. + +Find more about stacks [here](http://interactivepython.org/runestone/static/pythonds/BasicDS/WhatisaStack.html), queues [here](http://interactivepython.org/runestone/static/pythonds/BasicDS/WhatIsaQueue.html), and deques [here](http://interactivepython.org/runestone/static/pythonds/BasicDS/WhatIsaDeque.html). diff --git a/android-chrome-192x192.png b/android-chrome-192x192.png new file mode 100644 index 0000000..fe44068 Binary files /dev/null and b/android-chrome-192x192.png differ diff --git a/android-chrome-512x512.png b/android-chrome-512x512.png new file mode 100644 index 0000000..93c57cc Binary files /dev/null and b/android-chrome-512x512.png differ diff --git a/apple-touch-icon-120x120.png b/apple-touch-icon-120x120.png new file mode 100644 index 0000000..6518d8c Binary files /dev/null and b/apple-touch-icon-120x120.png differ diff --git a/apple-touch-icon-152x152.png b/apple-touch-icon-152x152.png new file mode 100644 index 0000000..ce4eade Binary files /dev/null and b/apple-touch-icon-152x152.png differ diff --git a/apple-touch-icon-180x180.png b/apple-touch-icon-180x180.png new file mode 100644 index 0000000..6dbaa93 Binary files /dev/null and b/apple-touch-icon-180x180.png differ diff --git a/apple-touch-icon-60x60.png b/apple-touch-icon-60x60.png new file mode 100644 index 0000000..34712b5 Binary files /dev/null and b/apple-touch-icon-60x60.png differ diff --git a/apple-touch-icon-76x76.png b/apple-touch-icon-76x76.png new file mode 100644 index 0000000..9c2c28c Binary files /dev/null and b/apple-touch-icon-76x76.png differ diff --git a/apple-touch-icon.png b/apple-touch-icon.png new file mode 100644 index 0000000..6dbaa93 Binary files /dev/null and b/apple-touch-icon.png differ diff --git a/browserconfig.xml b/browserconfig.xml new file mode 100644 index 0000000..25af1b4 --- /dev/null +++ b/browserconfig.xml @@ -0,0 +1,10 @@ + + + + + + + #00aba9 + + + diff --git a/css/main.scss b/css/main.scss new file mode 100644 index 0000000..047ea32 --- /dev/null +++ b/css/main.scss @@ -0,0 +1,58 @@ +--- +# Only the main Sass file needs front matter (the dashes are enough) +--- +@charset "utf-8"; + + + +// Our variables +$base-font-family: "Helvetica Neue", Helvetica, Arial, sans-serif; +$base-font-size: 16px; +$base-font-weight: 400; +$small-font-size: $base-font-size * 0.875; +$base-line-height: 1.5; + +$spacing-unit: 30px; + +$text-color: #111; +$background-color: #fdfdfd; +$brand-color: #2a7ae2; + +$grey-color: #828282; +$grey-color-light: lighten($grey-color, 40%); +$grey-color-dark: darken($grey-color, 25%); + +// Width of the content area +$content-width: 800px; + +$on-palm: 600px; +$on-laptop: 800px; + + + +// Use media queries like this: +// @include media-query($on-palm) { +// .wrapper { +// padding-right: $spacing-unit / 2; +// padding-left: $spacing-unit / 2; +// } +// } +@mixin media-query($device) { + @media screen and (max-width: $device) { + @content; + } +} + +@mixin media-larger($device) { + @media screen and (min-width: $device) { + @content; + } +} + + +// Import partials from `sass_dir` (defaults to `_sass`) +@import + "base", + "layout", + "syntax-highlighting" +; diff --git a/faculty/arlin.jpg b/faculty/arlin.jpg new file mode 100644 index 0000000..5e2478f Binary files /dev/null and b/faculty/arlin.jpg differ diff --git a/faculty/bubacarr.jpg b/faculty/bubacarr.jpg new file mode 100644 index 0000000..9ec7037 Binary files /dev/null and b/faculty/bubacarr.jpg differ diff --git a/faculty/carl.jpg b/faculty/carl.jpg new file mode 100644 index 0000000..620b29f Binary files /dev/null and b/faculty/carl.jpg differ diff --git a/faculty/index.md b/faculty/index.md new file mode 100644 index 0000000..ce3ffce --- /dev/null +++ b/faculty/index.md @@ -0,0 +1,6 @@ +--- +layout: people +permalink: /faculty/ +--- +{% for prof in site.faculty %}{% include faculty.md profile=prof %} +{% endfor %} \ No newline at end of file diff --git a/faculty/perceval.jpg b/faculty/perceval.jpg new file mode 100644 index 0000000..7e90f6b Binary files /dev/null and b/faculty/perceval.jpg differ diff --git a/faculty/tom.jpg b/faculty/tom.jpg new file mode 100644 index 0000000..1d1bb31 Binary files /dev/null and b/faculty/tom.jpg differ diff --git a/favicon-16x16.png b/favicon-16x16.png new file mode 100644 index 0000000..734cb5e Binary files /dev/null and b/favicon-16x16.png differ diff --git a/favicon-194x194.png b/favicon-194x194.png new file mode 100644 index 0000000..4308973 Binary files /dev/null and b/favicon-194x194.png differ diff --git a/favicon-32x32.png b/favicon-32x32.png new file mode 100644 index 0000000..62de17f Binary files /dev/null and b/favicon-32x32.png differ diff --git a/favicon.ico b/favicon.ico new file mode 100644 index 0000000..75b0ecc Binary files /dev/null and b/favicon.ico differ diff --git a/firefox_app_128x128.png b/firefox_app_128x128.png new file mode 100644 index 0000000..47e6c1d Binary files /dev/null and b/firefox_app_128x128.png differ diff --git a/firefox_app_512x512.png b/firefox_app_512x512.png new file mode 100644 index 0000000..c3c9c34 Binary files /dev/null and b/firefox_app_512x512.png differ diff --git a/firefox_app_60x60.png b/firefox_app_60x60.png new file mode 100644 index 0000000..6c42728 Binary files /dev/null and b/firefox_app_60x60.png differ diff --git a/flyer.pdf b/flyer.pdf new file mode 100644 index 0000000..4cad1e3 Binary files /dev/null and b/flyer.pdf differ diff --git a/index.md b/index.md new file mode 100644 index 0000000..2b07fd0 --- /dev/null +++ b/index.md @@ -0,0 +1,17 @@ +--- +layout: default +--- +{::options parse_block_html="true" /} +
{% include applications.md %} +Welcome to the ***Software Engineering for Applied Mathematical Sciences*** (***SEAMS*** for short) site! We are currently in the planning phase for a 2025 workshop! + +At SEAMS, we prepare scientists for the challenges of computationally-oriented research program. We have two offerings: the *Principles* course covering our five topic focuses and the *Workshop* which incorporates a hack-a-thon **on your project** in addition to the course material. + +We are pleased to announce that SEAMS has become part of the [International Clinics on Infectious Disease Dynamics and Data (ICI3D)](https://www.ici3d.org/). We will be migrating this site and our other materials to that umbrella soon, but we will leave a redirect here once that happens. + +The most recent *Workshop* was held in Februrary and March 2023 in partnership with [SACEMA](http://www.sacema.org/) in Stellenbosch, South Africa. We plan to offer *Workshop* again in February 2025 in partnership with [CEMA](https://cema-africa.uonbi.ac.ke/) in Nairobi, Kenya. + +For information on early iterations of the workshop, please see the {% include oldlink.md tx='old website' %}. [Seest recent participants](participants/dec2018/) and [their feedback on the program](past). + +***SEAMS*** has been made possible by contributions from {% include lo.md tx='AIMS' l='https://www.nexteinstein.org/' %} {% include lo.md tx='South Africa' l='https://aims.ac.za/' %} and {% include lo.md tx='Ghana' l='https://aims.edu.gh/' %}, {% include lo.md tx='ONR' l='https://www.onr.navy.mil/' %} and {% include lo.md tx='USAFRICOM' l='https://www.africom.mil' %}, {% include lo.md tx='University of Florida' l='https://biology.ufl.edu/' %}, {% include lo.md tx='SACEMA' l='http://www.sacema.org' %}, and other partners. +
diff --git a/logo-AIMS.png b/logo-AIMS.png new file mode 100644 index 0000000..2daafdc Binary files /dev/null and b/logo-AIMS.png differ diff --git a/logo-SACEMA.jpg b/logo-SACEMA.jpg new file mode 100644 index 0000000..c5dbdad Binary files /dev/null and b/logo-SACEMA.jpg differ diff --git a/logo-SACEMA.svg b/logo-SACEMA.svg new file mode 100644 index 0000000..a6dde5f --- /dev/null +++ b/logo-SACEMA.svg @@ -0,0 +1,540 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/logo-SEAMS-loc.png b/logo-SEAMS-loc.png new file mode 100644 index 0000000..7687439 Binary files /dev/null and b/logo-SEAMS-loc.png differ diff --git a/logo-SEAMS-loc.svg b/logo-SEAMS-loc.svg new file mode 100644 index 0000000..62f102a --- /dev/null +++ b/logo-SEAMS-loc.svg @@ -0,0 +1,19 @@ + + + + + + + + + + + + + + + + + diff --git a/logo-SEAMS-rev.png b/logo-SEAMS-rev.png new file mode 100644 index 0000000..9934071 Binary files /dev/null and b/logo-SEAMS-rev.png differ diff --git a/logo-SEAMS-rev.svg b/logo-SEAMS-rev.svg new file mode 100644 index 0000000..ff2444c --- /dev/null +++ b/logo-SEAMS-rev.svg @@ -0,0 +1,19 @@ + + + + + + + + + + + + + + + + + diff --git a/logo-SEAMS.png b/logo-SEAMS.png new file mode 100644 index 0000000..36a0591 Binary files /dev/null and b/logo-SEAMS.png differ diff --git a/logo-SEAMS.svg b/logo-SEAMS.svg new file mode 100644 index 0000000..5adca47 --- /dev/null +++ b/logo-SEAMS.svg @@ -0,0 +1,18 @@ + + + + + + + + + + + + + + + + diff --git a/logo-africom.png b/logo-africom.png new file mode 100644 index 0000000..1098927 Binary files /dev/null and b/logo-africom.png differ diff --git a/logo-humboldt.png b/logo-humboldt.png new file mode 100644 index 0000000..7f929f9 Binary files /dev/null and b/logo-humboldt.png differ diff --git a/manifest.webapp b/manifest.webapp new file mode 100644 index 0000000..191a120 --- /dev/null +++ b/manifest.webapp @@ -0,0 +1,14 @@ +{ + "version": "1.0", + "name": "SEAMS", + "description": "SEAMS Workshop Site", + "icons": { + "60": "/firefox_app_60x60.png?v=9ByMXnMyX4", + "128": "/firefox_app_128x128.png?v=9ByMXnMyX4", + "512": "/firefox_app_512x512.png?v=9ByMXnMyX4" + }, + "developer": { + "name": "SEAMS Faculty", + "url": "https://seams-workshop.gitlab.io/" + } +} diff --git a/mergerequest.json b/mergerequest.json new file mode 100644 index 0000000..c84ef6d --- /dev/null +++ b/mergerequest.json @@ -0,0 +1,6 @@ +{ + "id": 7337508, + "source_branch": "REPLACEME", + "target_branch": "master", + "title": "WIP: finish REPLACEME and merge master" +} \ No newline at end of file diff --git a/mstile-144x144.png b/mstile-144x144.png new file mode 100644 index 0000000..6c1a423 Binary files /dev/null and b/mstile-144x144.png differ diff --git a/mstile-150x150.png b/mstile-150x150.png new file mode 100644 index 0000000..c50faf1 Binary files /dev/null and b/mstile-150x150.png differ diff --git a/mstile-310x310.png b/mstile-310x310.png new file mode 100644 index 0000000..165ee05 Binary files /dev/null and b/mstile-310x310.png differ diff --git a/open-graph.png b/open-graph.png new file mode 100644 index 0000000..54f5b3f Binary files /dev/null and b/open-graph.png differ diff --git a/participants/dec2018/awe.jpg b/participants/dec2018/awe.jpg new file mode 100644 index 0000000..1209437 Binary files /dev/null and b/participants/dec2018/awe.jpg differ diff --git a/participants/dec2018/awe.pdf b/participants/dec2018/awe.pdf new file mode 100755 index 0000000..7467009 Binary files /dev/null and b/participants/dec2018/awe.pdf differ diff --git a/participants/dec2018/bingham.jpg b/participants/dec2018/bingham.jpg new file mode 100644 index 0000000..1503433 Binary files /dev/null and b/participants/dec2018/bingham.jpg differ diff --git a/participants/dec2018/bingham.pdf b/participants/dec2018/bingham.pdf new file mode 100755 index 0000000..75334b2 Binary files /dev/null and b/participants/dec2018/bingham.pdf differ diff --git a/participants/dec2018/bruce.jpg b/participants/dec2018/bruce.jpg new file mode 100644 index 0000000..3157a7d Binary files /dev/null and b/participants/dec2018/bruce.jpg differ diff --git a/participants/dec2018/bruce.pdf b/participants/dec2018/bruce.pdf new file mode 100755 index 0000000..27d15a1 Binary files /dev/null and b/participants/dec2018/bruce.pdf differ diff --git a/participants/dec2018/burengengwa.jpg b/participants/dec2018/burengengwa.jpg new file mode 100644 index 0000000..cea4e17 Binary files /dev/null and b/participants/dec2018/burengengwa.jpg differ diff --git a/participants/dec2018/burengengwa.pdf b/participants/dec2018/burengengwa.pdf new file mode 100755 index 0000000..bdcc583 Binary files /dev/null and b/participants/dec2018/burengengwa.pdf differ diff --git a/participants/dec2018/delva.jpg b/participants/dec2018/delva.jpg new file mode 100644 index 0000000..4488fc6 Binary files /dev/null and b/participants/dec2018/delva.jpg differ diff --git a/participants/dec2018/delva.pdf b/participants/dec2018/delva.pdf new file mode 100755 index 0000000..0a934ba Binary files /dev/null and b/participants/dec2018/delva.pdf differ diff --git a/participants/dec2018/geza.pdf b/participants/dec2018/geza.pdf new file mode 100755 index 0000000..f1f679e Binary files /dev/null and b/participants/dec2018/geza.pdf differ diff --git a/participants/dec2018/geza.png b/participants/dec2018/geza.png new file mode 100644 index 0000000..6831c19 Binary files /dev/null and b/participants/dec2018/geza.png differ diff --git a/participants/dec2018/index.md b/participants/dec2018/index.md new file mode 100644 index 0000000..f51d973 --- /dev/null +++ b/participants/dec2018/index.md @@ -0,0 +1,11 @@ +--- +layout: people +--- +### Held at AIMS South Africa, Muizenberg from 26 November to 7 December 2018. + +![2018 Participants](participants.jpg) + +*** + +{% assign people = site.data.dec2018 %}{% if people.size > 0%}{% assign people = people | sort %}{% for p in people %}{% assign part = p[1] %}{% if part.status == 'complete' %}{% include faculty.md profile=part %} +{% endif %}{% endfor %}{% else %}No participants!{% endif %} \ No newline at end of file diff --git a/participants/dec2018/kanubala.jpeg b/participants/dec2018/kanubala.jpeg new file mode 100644 index 0000000..7993630 Binary files /dev/null and b/participants/dec2018/kanubala.jpeg differ diff --git a/participants/dec2018/kanubala.pdf b/participants/dec2018/kanubala.pdf new file mode 100755 index 0000000..4fb87c2 Binary files /dev/null and b/participants/dec2018/kanubala.pdf differ diff --git a/participants/dec2018/maher.jpg b/participants/dec2018/maher.jpg new file mode 100644 index 0000000..4442a7f Binary files /dev/null and b/participants/dec2018/maher.jpg differ diff --git a/participants/dec2018/maher.pdf b/participants/dec2018/maher.pdf new file mode 100755 index 0000000..da2e585 Binary files /dev/null and b/participants/dec2018/maher.pdf differ diff --git a/participants/dec2018/mateyisi.jpg b/participants/dec2018/mateyisi.jpg new file mode 100755 index 0000000..18ede78 Binary files /dev/null and b/participants/dec2018/mateyisi.jpg differ diff --git a/participants/dec2018/mateyisi.pdf b/participants/dec2018/mateyisi.pdf new file mode 100755 index 0000000..fda22f5 Binary files /dev/null and b/participants/dec2018/mateyisi.pdf differ diff --git a/participants/dec2018/mbewe.jpg b/participants/dec2018/mbewe.jpg new file mode 100644 index 0000000..8fdce4a Binary files /dev/null and b/participants/dec2018/mbewe.jpg differ diff --git a/participants/dec2018/mensah.pdf b/participants/dec2018/mensah.pdf new file mode 100755 index 0000000..9f6ef5c Binary files /dev/null and b/participants/dec2018/mensah.pdf differ diff --git a/participants/dec2018/mensah.png b/participants/dec2018/mensah.png new file mode 100644 index 0000000..84050ac Binary files /dev/null and b/participants/dec2018/mensah.png differ diff --git a/participants/dec2018/mhlanga.jpg b/participants/dec2018/mhlanga.jpg new file mode 100644 index 0000000..dd23d1e Binary files /dev/null and b/participants/dec2018/mhlanga.jpg differ diff --git a/participants/dec2018/mhlanga.pdf b/participants/dec2018/mhlanga.pdf new file mode 100755 index 0000000..636ef00 Binary files /dev/null and b/participants/dec2018/mhlanga.pdf differ diff --git a/participants/dec2018/ndege.jpg b/participants/dec2018/ndege.jpg new file mode 100644 index 0000000..fe11c76 Binary files /dev/null and b/participants/dec2018/ndege.jpg differ diff --git a/participants/dec2018/ndege.pdf b/participants/dec2018/ndege.pdf new file mode 100755 index 0000000..711e9c4 Binary files /dev/null and b/participants/dec2018/ndege.pdf differ diff --git a/participants/dec2018/participants.jpg b/participants/dec2018/participants.jpg new file mode 100644 index 0000000..1f5f28d Binary files /dev/null and b/participants/dec2018/participants.jpg differ diff --git a/participants/dec2018/rabetokotany.jpg b/participants/dec2018/rabetokotany.jpg new file mode 100644 index 0000000..2be3877 Binary files /dev/null and b/participants/dec2018/rabetokotany.jpg differ diff --git a/participants/dec2018/rabetokotany.pdf b/participants/dec2018/rabetokotany.pdf new file mode 100755 index 0000000..d0948ac Binary files /dev/null and b/participants/dec2018/rabetokotany.pdf differ diff --git a/participants/dec2018/sefara.jpg b/participants/dec2018/sefara.jpg new file mode 100644 index 0000000..2775696 Binary files /dev/null and b/participants/dec2018/sefara.jpg differ diff --git a/participants/dec2018/sefara.pdf b/participants/dec2018/sefara.pdf new file mode 100755 index 0000000..5ec6f11 Binary files /dev/null and b/participants/dec2018/sefara.pdf differ diff --git a/participants/dec2018/toussaint.jpg b/participants/dec2018/toussaint.jpg new file mode 100644 index 0000000..9a8d20c Binary files /dev/null and b/participants/dec2018/toussaint.jpg differ diff --git a/participants/dec2018/toussant.pdf b/participants/dec2018/toussant.pdf new file mode 100755 index 0000000..4892a89 Binary files /dev/null and b/participants/dec2018/toussant.pdf differ diff --git a/participants/index.md b/participants/index.md new file mode 100644 index 0000000..9d278c4 --- /dev/null +++ b/participants/index.md @@ -0,0 +1,10 @@ +--- +layout: people +permalink: /participants/ +--- +{% assign people = site.data.jan2020 %}{% if people.size > 0 %}{% assign people = people | sort %}{% for p in people %}{% assign part = p[1] %}{% include faculty.md profile=part path='jan2020/' %} +{% endfor %}{% else %}No participants submitted their profile 2020...yet!{% endif %} + +*** + +See past participants: [2018](dec2018/) diff --git a/participants/jan2020/Elisha.jpg b/participants/jan2020/Elisha.jpg new file mode 100644 index 0000000..7b9edba Binary files /dev/null and b/participants/jan2020/Elisha.jpg differ diff --git a/participants/jan2020/Mthombothi.jpg b/participants/jan2020/Mthombothi.jpg new file mode 100644 index 0000000..afcf3ef Binary files /dev/null and b/participants/jan2020/Mthombothi.jpg differ diff --git a/participants/jan2020/Suboi.jpg b/participants/jan2020/Suboi.jpg new file mode 100644 index 0000000..a5091b3 Binary files /dev/null and b/participants/jan2020/Suboi.jpg differ diff --git a/participants/jan2020/ebrahim.jpeg b/participants/jan2020/ebrahim.jpeg new file mode 100644 index 0000000..0aa603c Binary files /dev/null and b/participants/jan2020/ebrahim.jpeg differ diff --git a/participants/jan2020/emanuel.jpg b/participants/jan2020/emanuel.jpg new file mode 100644 index 0000000..9fa94c3 Binary files /dev/null and b/participants/jan2020/emanuel.jpg differ diff --git a/participants/jan2020/index.md b/participants/jan2020/index.md new file mode 100644 index 0000000..3221943 --- /dev/null +++ b/participants/jan2020/index.md @@ -0,0 +1,11 @@ +--- +layout: people +--- +### Held at SACEMA, Stellenbosch from 20-31 January 2020. + +![2020 Participants](participants.jpg) + +*** + +{% assign people = site.data.jan2020 %}{% if people.size > 0%}{% assign people = people | sort %}{% for p in people %}{% assign part = p[1] %}{% if part.status == 'complete' %}{% include faculty.md profile=part %} +{% endif %}{% endfor %}{% else %}No participants!{% endif %} diff --git a/participants/jan2020/james.jpg b/participants/jan2020/james.jpg new file mode 100644 index 0000000..4e7ed92 Binary files /dev/null and b/participants/jan2020/james.jpg differ diff --git a/participants/jan2020/larisse.jpg b/participants/jan2020/larisse.jpg new file mode 100644 index 0000000..0e4acfd Binary files /dev/null and b/participants/jan2020/larisse.jpg differ diff --git a/participants/jan2020/loynaps.jpg b/participants/jan2020/loynaps.jpg new file mode 100644 index 0000000..f0b9e37 Binary files /dev/null and b/participants/jan2020/loynaps.jpg differ diff --git a/participants/jan2020/marijn.jpg b/participants/jan2020/marijn.jpg new file mode 100644 index 0000000..1542b84 Binary files /dev/null and b/participants/jan2020/marijn.jpg differ diff --git a/participants/jan2020/pulliam.jpg b/participants/jan2020/pulliam.jpg new file mode 100644 index 0000000..7c0c3b9 Binary files /dev/null and b/participants/jan2020/pulliam.jpg differ diff --git a/participants/jan2020/sulaimon.jpg b/participants/jan2020/sulaimon.jpg new file mode 100644 index 0000000..e629306 Binary files /dev/null and b/participants/jan2020/sulaimon.jpg differ diff --git a/past/index.md b/past/index.md new file mode 100644 index 0000000..bc6ac41 --- /dev/null +++ b/past/index.md @@ -0,0 +1,18 @@ +--- +layout: default +permalink: /past/ +--- + +## 2018 Workshop Participant Comments + +> The SEAMS workshop condensed what could have easily been two months of code hacking into a productive and high intensity 2 week programme. The balance of practical to theoretical activities was great, the facilitators know their subject areas deeply and the delivery of my research outputs was accelerated thanks to the training. + +> The amount of resources, knowledge and information provided during the workshop is priceless. It helped me move many steps further to the success of my project in 2 weeks than I would have spent in 2 months of office work. Thank you. + +> Highly interactive workshop, addressing a huge knowledge and skills gap in data science and software engineering. I felt very fortunate to be able to participate in this workshop. It was a primer, a consolidator, an inspiration for many aspects and areas in my current and future work. + +> [W]ith no formal background in computer programming, I’ve oftentimes suspected that my workflow has been less efficient and more time-consuming that it needed to be. Sharing work with colleagues was also oftentimes challenging. The workshop provided me with some excellent, basic best-practices for working on collaborative projects that involve programming and software development. I particularly appreciated the sessions on workspace organization and tools and reuse and reusability. I fully expect to use the skills and knowledge that I acquired during the workshop to improve the quality and efficiency of my professional work on future projects. + +> This workshop tops the list of the workshops that I have attended. It is very student centered and you do get value for the time spent on it. The course offers a skill that is not exhaustively taught anywhere, but people always have to learn the hard way on good practices and the course touches this very well. I would recommend the course to other people interested in software development and not forgetting that the faculty members are knowledgeable and very attentive to their students and always give valuable feedback and can troubleshoot the problem with you. + +> The workshop provides a platform for participants from different programming level backgrounds to all learn a new skill. Prior to the workshop I thought my coding/organisational/workflow skills were not too bad. I can now confidently say, at the end of the workshop, that is was actually embarrassingly bad. All the concepts taught throughout the workshop were familiar in that I heard about them but never quite understood the "how" to implement them. In addition, the implementation on a project that is relevant to your own work was extremely valuable. I learnt so much, not only from the lectures, practicals and faculty, but also from the participants. Assistance and advice on my project was available throughout the 2 weeks. The faculty were available throughout the workshop, even during "break times", to chat, give advice and ideas, discuss progress and advise on the way forward. I would very highly recommend the workshop to anyone working on a project, irrespective of the progress/stage of the project. I sincerely thank the faculty and organizers! Awesome job!!! diff --git a/practical/hpc/hpcExample.R b/practical/hpc/hpcExample.R new file mode 100644 index 0000000..d2f0dda --- /dev/null +++ b/practical/hpc/hpcExample.R @@ -0,0 +1,26 @@ +require(data.table) + +diceSim <- function(numDice=6L, numFaces=6L, numSamples=1e6) { + reference <- data.table(dicesum=1L:(numDice*numFaces), count = 0L) + for (x in 1:numSamples) { + rolls <- sample(numFaces, numDice, replace = T) + ds <- sum(rolls) + reference[ds, count := count + 1L ] + } + reference +} + +# takes about 3 seconds for 1e4 samples => 300 seconds for 1e6 samples + +faces <- seq(2L, 10L, by=2L) +counts <- seq(2L, 10L, by=2L) + +sample.grid <- data.table(expand.grid(faces = faces, counts = counts)) + +# 300 seconds x 25 combinations = 7500s = 2 hrs + +# ...now data.table is a bit clever on threading, so will probably finish sooner than 2 hours, depending on cores +sample.grid[,{ + res <- diceSim(counts, faces, 1e6) + saveRDS(res, sprintf("%02i_%02i.rds", counts, faces)) +}, by=.(faces, counts)] diff --git a/practical/io/files-from-Pat.zip b/practical/io/files-from-Pat.zip new file mode 100644 index 0000000..8248364 Binary files /dev/null and b/practical/io/files-from-Pat.zip differ diff --git a/practical/io/io-practical-figure.jpg b/practical/io/io-practical-figure.jpg new file mode 100644 index 0000000..ffd9e27 Binary files /dev/null and b/practical/io/io-practical-figure.jpg differ diff --git a/practical/workspace/cfr_project.tgz b/practical/workspace/cfr_project.tgz new file mode 100644 index 0000000..eb91450 Binary files /dev/null and b/practical/workspace/cfr_project.tgz differ diff --git a/rfg.json b/rfg.json new file mode 100644 index 0000000..35e528d --- /dev/null +++ b/rfg.json @@ -0,0 +1,83 @@ +{ + "favicon_generation": { + "api_key": "REPLACEME", + "master_picture": { + "type": "url", + "url": "http://seams-workshop.gitlab.io/logo-SEAMS.png" + }, + "files_location": { + "type": "root" + }, + "favicon_design": { + "desktop_browser": {}, + "ios": { + "picture_aspect": "background_and_margin", + "margin": "4", + "background_color": "#ffffff", + "assets": { + "ios6_and_prior_icons": false, + "ios7_and_later_icons": true, + "precomposed_icons": false, + "declare_only_default_icon": true + }, + "app_name": "SEAMS" + }, + "windows": { + "picture_aspect": "white_silhouette", + "background_color": "#00aba9", + "assets": { + "windows_80_ie_10_tile": true, + "windows_10_ie_11_edge_tiles": { + "small": false, + "medium": true, + "big": true, + "rectangle": false + } + } + }, + "firefox_app": { + "picture_aspect": "circle", + "keep_picture_in_circle": "true", + "circle_inner_margin": "5", + "background_color": "#ffffff", + "manifest": { + "app_name": "SEAMS", + "app_description": "SEAMS Workshop Site", + "developer_name": "SEAMS Faculty", + "developer_url": "https://seams-workshop.gitlab.io/" + } + }, + "android_chrome": { + "picture_aspect": "background_and_margin", + "margin": "4", + "background_color": "#ffffff", + "manifest": { + "name": "SEAMS", + "display": "browser", + "start_url": "https://seams-workshop.gitlab.io/", + "existing_manifest": "{\"name\": \"SEAMS Workshop Site\"}" + }, + "assets": { + "legacy_icon": true, + "low_resolution_icons": false + }, + "theme_color": "#4972ab" + }, + "open_graph": { + "picture_aspect": "background_and_margin", + "background_color": "#ffffff", + "margin": "12%", + "ratio": "square" + } + }, + "settings": { + "compression": "0", + "scaling_algorithm": "Mitchell", + "error_on_image_too_small": true, + "readme_file": false, + "html_code_file": true, + "use_path_as_is": false + }, + "versioning": true + } +} diff --git a/site.webmanifest b/site.webmanifest new file mode 100644 index 0000000..172dc7f --- /dev/null +++ b/site.webmanifest @@ -0,0 +1,20 @@ +--- +--- +{ + "name": "SEAMS Workshop Site", + "icons": [ + { + "src": "{{ '/android-chrome-192x192.png?v=9ByMXnMyX4' | relative_url }}", + "sizes": "192x192", + "type": "image/png" + }, + { + "src": "{{ '/android-chrome-512x512.png?v=9ByMXnMyX4' | relative_url }}", + "sizes": "512x512", + "type": "image/png" + } + ], + "theme_color": "#4972ab", + "background_color": "#4972ab", + "start_url": "{{ '/' | relative_url }}" +}