Skip to content

Instantly share code, notes, and snippets.

View pwightman's full-sized avatar

Parker Wightman pwightman

View GitHub Profile
@pwightman
pwightman / letterpress_solver.clj
Last active August 29, 2015 13:56
Letterpress Solver
(ns letterpress-solver.core
(:require [clojure.string :as string]))
(def letters "srrbt
sdofa
ghvyp
ksbkk
begnv")

Which do you prefer? (name key is object's unique identifier)

[
  {
    "name": "bob",
    "foo": "bar"
  },
  {
 "name": "alice",
// I swiped this from a stack overflow question somewhere, it works well.
window.getParameterByName = function(name) {
name = name.replace(/[\[]/, "\\\[").replace(/[\]]/, "\\\]");
var regexS = "[\\?&]" + name + "=([^&#]*)";
var regex = new RegExp(regexS);
var results = regex.exec(window.location.search);
if(results == null)
return "";
else
return decodeURIComponent(results[1].replace(/\+/g, " "));
@pwightman
pwightman / se.md
Last active December 28, 2015 09:29

Development Process

We plan on leveraging the Agile development process, so that we can iterate quickly. We will initially have one week sprints while we get our bearings, and then move to two week sprints. We will begin each sprint with a sprint review, where we discuss where we are at and how things went, followed by sprint planning, where we make new, specific tasks for each of us, applying what we learned in the sprint review.

Version Control

We will be using Git as our version control system and GitHub as our VCS host. Git is very friendly to Agile development as branching and merging is simple. We will have three kinds of branches:

  • Stable branch - this is where stable, production-ready code is kept. We will only merge into master when we have “releases."
  • Feature branches - Each team member will develop new features inside their own branch. This branch will usually be local to the developer’s machine and not exposed to the rest of the team (unless they need to pull in help from others).

Group

Note: * is some generic operator, not necessarily multiplication

  • Closure - a in S, b in S, a * b in S
  • Associativity - a + (b + c) = (a + b) + c
  • Identity - for all a in S, a * i = a, where i is identity element
  • Inverse - for all a in S, there exists b in S such that a * b = b * a = e where e is identity element

Ring

{
"traits": [
{
"id": "Draggable",
"properties": {
"up": true,
"down": true,
"left": true,
"right": true
},
var foo;

How I Wish Racket Was First Explained To Me

I've been taking a compilers class this semester from Matt Might, which has been a great experience. Amongst the most challenging/interesting aspects of the course has been taming Racket, a Scheme-y/LISP-y language (I'll leave it at that).

Having never used anything functional/LISP-y in my days, this was a brand new experience. On the whole, it was good, but here's how I wish my first introduction to the language had gone as it would have set me on the right foot. While I'm focusing on Racket here, I imagine this same thing applies to LISP/Scheme and its derivatives.

Code vs. Data

I read everywhere that, "In Racket, code and data are the same thing." That sentence alone was useless to me, and it took a number of weeks before I "got it." Perhaps this explanation may have been more helpful:

//
// MTMigration.m
// Tracker
//
// Created by Parker Wightman on 2/7/13.
// Copyright (c) 2013 Mysterious Trousers. All rights reserved.
//
#import "MTMigration.h"

100x100 (20,000 cross table records)

Indexed

Airplane time: 0.009674359999999998
Test time: 0.009538310000000008

Not Indexed

Airplane time: 0.011953609999999995
Test time: 0.011936900000000005