Welcome!
UPDATE: This list is no longer maintained. I've moved it to its own repo so you can send suggestions as Pull Requests. https://github.com/dideler/bootstrapping/
For feedback or suggestions, please send a tweet (@dideler). Gist comments don't notify me. Pull requests aren't possible with gists (yet), so I don't recommend forking because then I can't easily get the change.
Starring this gist will give me an idea of how many people consider this list useful.
| #!/usr/bin/env python | |
| # vim: set fileencoding=utf-8: | |
| import pickle | |
| import json | |
| from math import exp | |
| from random import random | |
| from random import shuffle | |
| def sigmoid(x): |
Based on the article: Using checklists for code review
In general, people are pretty good at the code review process, but it's sometimes surprising what can slip through. A natural consequence of the way our brains look at the world is that it's easy to pay a lot of attention to small details and code style flubs, and completely miss the big picture.
Obviously, not everything is applicable for every change. If the review request isn't making any changes to UI, then skip the first two checklists entirely. If a change is a bug fix, typically don't review it for architecture and design principles.
Put the big stuff first (e.g. architecture). You don't want to work through a ton of small issues before realizing that everything has to be rewritten.
Do a pass through the code for each and every item in the checklist. By only looking for a very specific type of defect, each pass goes relatively quickly, even for large changes. Focu
For every power user that writes in asking for a feature, there’s one new user (and ten potential users) that felt the opposite way.
When you’re evaluating potential features, part of your role is to be an advocate for the long tail of users that won’t yet advocate for themselves.
#Non-mathematical Introductions
#Videos
You can move quickly through various full-stack troubleshooting tasks in our mission-critical distributed system; You are highly motivated to create extremely reliable, secure and performant pieces of software and processes; You are constructive and you take feedback well, incorporating it in your day-to-day tasks; Your communication skills are stellar, even when operating under stress; You don’t just hack something together; You craft incredibly polished pieces of code; Test driven development comes naturally to you; Reducing your code coverage is not an option for you; You have astonishing tracking skills; Your bugs are always up-to-date and your projects are delivered on time.
This is just a quick list of resourses on TDA that I put together for @rickasaurus after he was asking for links to papers, books, etc on Twitter and is by no means an exhaustive list.
Both Carlsson's and Ghrist's survey papers offer a very good introduction to the subject
Mapper algorithm.
If a project has to have multiple git repos (e.g. Bitbucket and Github) then it's better that they remain in sync.
Usually this would involve pushing each branch to each repo in turn, but actually Git allows pushing to multiple repos in one go.
If in doubt about what git is doing when you run these commands, just
| """ | |
| Programmer: Chris Tralie | |
| Purpose: To demonstrate a greedy furthest point sampling, which is a general technique | |
| for getting good points that are "spread out" and cover the dataset well | |
| """ | |
| import numpy as np | |
| import matplotlib.pyplot as plt | |
| from sklearn.metrics.pairwise import pairwise_distances | |
| def getGreedyPerm(D): |