├── 1407 ├── 07_self_directed_project │ ├── .gitkeep │ └── evaluations │ │ ├── aiken_luke.markdown │ │ ├── egbert_glen.markdown │ │ ├── wortham_aaron.markdown │ │ └── navarrete_rolando.markdown ├── 06_the_pivot │ ├── gallery.markdown │ ├── airlift.markdown │ ├── fresh_threads.markdown │ └── submissions.rb ├── 05_dinner_dash │ └── dinner_dash_submissions.yml ├── 01_mastermind │ └── mastermind_submissions.yml ├── 02_event_reporter │ └── event_reporter_submissions.yml └── 04_clone_wars │ └── clone_wars_submissions.yml ├── 1409 ├── 05_dinner_dash │ ├── checkins │ │ ├── kate-chandra-zach-alex │ │ ├── greg-viki-chase-konr │ │ ├── danny-adam-david │ │ └── herbert_travis_tim_sam │ └── dinner_dash_submissions.yml ├── 07_self_directed_project │ ├── vanhekken_chase.md │ ├── jensen_alex.md │ ├── larson_konr.md │ ├── harrod_viki.md │ ├── joseph_herbert.md │ ├── glunz_danny.md │ ├── carney_chandra.md │ ├── narajka_greg.md │ ├── yoder_travis.md │ ├── mee_tim.md │ ├── bayendor_david.md │ ├── kuhlmann_sam.md │ ├── lane_kate.md │ └── routhier_zach.md ├── 04_clone_wars │ ├── checkins │ │ ├── david-sam-alex │ │ ├── herbert-danny-kate │ │ ├── zach-travis-chase │ │ ├── tim-greg-konr │ │ └── adam-chandra-viki │ └── clone_wars_submissions.yml ├── 06_the_pivot │ └── submissions.yml └── 03_sales_engine │ └── sales_engine_submissions.yml ├── 1410 ├── 08_the_pivot │ └── the_pivot_submissions.yml ├── 04_ideabox │ └── ideabox_submissions.yml ├── 05_traffic_spy │ └── traffic_spy.yml ├── 06_mini_project │ └── 06_mini_project.yml ├── 07_dinner_dash │ └── dinner_dash_submissions.yml └── 02_event_reporter │ └── event_reporter_submissions.yml ├── 1412 ├── challenges │ ├── cryptographer.markdown │ └── chisel.markdown ├── 02_sales_engine │ └── sales_engine_eval.yml └── 03_traffic_spy │ └── traffic_spy.yml ├── 1502 └── challenges │ ├── credit_check.markdown │ └── chisel.markdown ├── scripts ├── Gemfile ├── provision_do_servers.rb ├── generate_outline.rb ├── Gemfile.lock ├── provisioner_do.rb └── provision_heroku_servers.rb ├── archive ├── 1406 │ ├── 07_self_directed_project │ │ ├── evaluations │ │ │ ├── tan_doan.markdown │ │ │ ├── garreau_marc.markdown │ │ │ ├── tim_proctor.markdown │ │ │ ├── jonmichael.markdown │ │ │ ├── hilary_denton.markdown │ │ │ ├── robert_gu.markdown │ │ │ ├── will_faurot.markdown │ │ │ ├── emily_davis.markdown │ │ │ ├── allison_larson.markdown │ │ │ ├── andy_mention.markdown │ │ │ └── eric_fransen.markdown │ │ ├── tim_proctor.markdown │ │ ├── chavez_horacio.md │ │ ├── davis_corey.markdown │ │ ├── will_faurot.md │ │ ├── chambers_jonmichael.markdown │ │ ├── garreau_marc.markdown │ │ ├── larson_allison.markdown │ │ ├── davis_emily.markdown │ │ ├── smith_alan.markdown │ │ ├── denton_hilary.markdown │ │ ├── brading_chad.markdown │ │ └── Gu_Robert.markdown │ ├── 09_mastery │ │ └── 01 - micro check-ins.markdown │ ├── 08_feed_engine │ │ ├── tunefish.markdown │ │ ├── snowcial.markdown │ │ ├── successive_life.markdown │ │ ├── footprints.markdown │ │ └── submissions.yml │ ├── 06_the_pivot │ │ ├── the_pivot.markdown │ │ ├── checkpoint_2.markdown │ │ └── final_eval.markdown │ ├── 05_dinner_dash │ │ └── dinner_dash_submissions.yml │ └── 02_event_reporter │ │ └── event_reporter_submissions.yml ├── gschool-0 │ ├── portfolios │ │ └── README.markdown │ ├── projects │ │ ├── mastery_project │ │ │ ├── student_lab.rb │ │ │ ├── project_name.rb │ │ │ ├── son_of_poem_engine.rb │ │ │ ├── clear_status.rb │ │ │ ├── enigmates.rb │ │ │ ├── daughter_of_new_leaf_massage.rb │ │ │ ├── socrada │ │ │ ├── artistic_streets.rb │ │ │ └── 2nd_bookshelf.rb │ │ ├── individual_projects │ │ │ ├── maddux_john.rb │ │ │ ├── steadman_laura.rb │ │ │ ├── tellez_jorge.rb │ │ │ ├── eliuk_jennifer.rb │ │ │ ├── maher_aimee.rb │ │ │ ├── sears_logan.rb │ │ │ ├── tai_elaine.rb │ │ │ ├── knight_chris.rb │ │ │ ├── drummond_erin.rb │ │ │ ├── lastname_firstname.rb │ │ │ ├── blackwell_paul.rb │ │ │ ├── rogers_shane │ │ │ ├── battos_phil.rb │ │ │ ├── grant_kareem.rb │ │ │ ├── garcia_danny.rb │ │ │ ├── schorkopf_geoffrey.rb │ │ │ ├── mee_daniel.rb │ │ │ ├── komlo_chelsea.rb │ │ │ ├── anderson_blair.rb │ │ │ ├── mejia_josh.rb │ │ │ ├── suss_kyle.rb │ │ │ ├── weiner_raphael.rb │ │ │ └── sheehan_bradley.rb │ │ ├── feed_engine.rb │ │ ├── warmup_exercises.markdown │ │ ├── daughter_of_store_engine.rb │ │ ├── son_of_store_engine.markdown │ │ ├── traffic_spy.markdown │ │ ├── sales_engine.markdown │ │ └── event_reporter.markdown │ ├── reading │ │ └── eloquent_ruby │ │ │ └── rg2 │ │ │ ├── group_7_notes.markdown │ │ │ ├── group_8_notes.markdown │ │ │ ├── README.markdown │ │ │ ├── group_4_notes.markdown │ │ │ ├── group_1_notes.markdown │ │ │ ├── group_6_notes.markdown │ │ │ ├── group_3_notes.markdown │ │ │ ├── group_2_notes.markdown │ │ │ └── group_5_notes.markdown │ └── writing │ │ └── index.markdown └── gschool-1 │ ├── reading │ └── cycle_5.markdown │ └── projects │ └── services.rb ├── README.md ├── .gitignore └── blogging ├── 2014-09-26.markdown └── 2014-10-03.markdown /1407/07_self_directed_project/.gitkeep: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /1502/challenges/credit_check.markdown: -------------------------------------------------------------------------------- 1 | ### Submissions 2 | -------------------------------------------------------------------------------- /scripts/Gemfile: -------------------------------------------------------------------------------- 1 | source "https://rubygems.org" 2 | 3 | gem 'digitalocean' -------------------------------------------------------------------------------- /archive/gschool-0/portfolios/README.markdown: -------------------------------------------------------------------------------- 1 | Moved to https://github.com/jumpstartlab/portfolio -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Submissions for Turing Ruby Courses 2 | 3 | This repository is used to collect submission urls and other data for Turing 4 | projects and assignments during the Ruby course. 5 | -------------------------------------------------------------------------------- /1407/07_self_directed_project/evaluations/aiken_luke.markdown: -------------------------------------------------------------------------------- 1 | Feature Completion: 3.5 2 | Project Completion: 4 3 | User Experience: 3 4 | Organization: 3 5 | Test-Driven Development: 1 6 | Code Quality: 3 7 | 8 | Demo: Yes 9 | -------------------------------------------------------------------------------- /1407/07_self_directed_project/evaluations/egbert_glen.markdown: -------------------------------------------------------------------------------- 1 | Feature Completion: 4 2 | Project Completion: 3.5 3 | User Experience: 4 4 | Organization: 2.5 5 | Test-Driven Development: 2 6 | Code Quality: 3.5 7 | 8 | Demo: Yes 9 | -------------------------------------------------------------------------------- /1407/07_self_directed_project/evaluations/wortham_aaron.markdown: -------------------------------------------------------------------------------- 1 | Feature Completion: 3 2 | Project Completion: 3 3 | User Experience: 2 4 | Organization: 2.5 5 | Test-Driven Development: 1 6 | Code Quality: 2.5 7 | 8 | Demo: Yes 9 | -------------------------------------------------------------------------------- /1407/07_self_directed_project/evaluations/navarrete_rolando.markdown: -------------------------------------------------------------------------------- 1 | Feature Completion: 2.5 2 | Project Completion: 3 3 | User Experience: 3 4 | Organization: 3 5 | Test-Driven Development: 2.5 6 | Code Quality: 3 7 | 8 | Demo: Yes 9 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | *.gem 2 | *.rbc 3 | .bundle 4 | .config 5 | coverage 6 | InstalledFiles 7 | lib/bundler/man 8 | pkg 9 | rdoc 10 | spec/reports 11 | test/tmp 12 | test/version_tmp 13 | tmp 14 | 15 | # YARD artifacts 16 | .yardoc 17 | _yardoc 18 | doc/ 19 | .DS_Store -------------------------------------------------------------------------------- /scripts/provision_do_servers.rb: -------------------------------------------------------------------------------- 1 | require_relative 'provisioner_do' 2 | 3 | students = [ 4 | 'horace' 5 | ] 6 | 7 | pro = Provisioner::DO.new 8 | students.each do |student| 9 | name = student.downcase.scan(/\w/).join 10 | droplet = pro.provision_server(name) 11 | puts "Provisioned #{name}: #{droplet.inspect}" 12 | end 13 | -------------------------------------------------------------------------------- /scripts/generate_outline.rb: -------------------------------------------------------------------------------- 1 | require_relative '../gschool-1/projects/services' 2 | 3 | project.each do |name, values| 4 | puts "### #{values[:project_name]}" 5 | puts "" 6 | puts "* Team: #{values[:members].join(', ')}" 7 | puts "* Code: #{values[:repo_url]}" 8 | puts "* Production: #{values[:production_url]}" 9 | puts "" 10 | end -------------------------------------------------------------------------------- /archive/gschool-0/projects/mastery_project/student_lab.rb: -------------------------------------------------------------------------------- 1 | { 2 | :developers => ["Jorge Téllez"] 3 | :project_name => "Student Lab", 4 | :project_description => "A student CRM for JumpstartLab", 5 | :backend_technologies => ['MongoDB'], 6 | :frontend_technologies => ['Backbone.js'] 7 | :repo => 'http://github.com/novohispano/student_lab' 8 | } -------------------------------------------------------------------------------- /archive/gschool-0/projects/mastery_project/project_name.rb: -------------------------------------------------------------------------------- 1 | { 2 | :developers => ["First Last 1", "First Last 2"] 3 | :project_name => "The Project Name", 4 | :project_description => "One paragraph about what the app will do and why", 5 | :backend_technologies => ['riak'], 6 | :frontend_technologies => ['D3'] 7 | :repo => 'http://github.com/username/repo_name' 8 | } 9 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/mastery_project/son_of_poem_engine.rb: -------------------------------------------------------------------------------- 1 | { 2 | :developers => ["Daniel Mee 1"] 3 | :project_name => "Son of Poem Engine", 4 | :project_description => "Think my first solo project...but complete, functional, and tested.", 5 | :backend_technologies => ['Postgres'], 6 | :frontend_technologies => ['jQuery'] 7 | :repo => 'http://github.com/danmee10/mastery_project' 8 | } 9 | -------------------------------------------------------------------------------- /1409/05_dinner_dash/checkins/kate-chandra-zach-alex: -------------------------------------------------------------------------------- 1 | Checkin with: Horace 2 | Zach, Kate, Chandra, Alex 3 | 4 | Done: 5 | - basic frontend infrastructure coming together 6 | - db schema still quite minimal; need to model more of domain 7 | - code looking clean so far but not too much done 8 | 9 | todo: 10 | - don't use ApplicaitonController for rendering actual endpoints - migrate root to use index of another controller 11 | -------------------------------------------------------------------------------- /1410/08_the_pivot/the_pivot_submissions.yml: -------------------------------------------------------------------------------- 1 | Laura, Brandon, Rich, Alexandra, Konr: 2 | repository: "https://github.com/larsonkonr/The_Pivot" 3 | 4 | Krista, Nathan, Bhargavi, Scott: 5 | repository: "https://github.com/KristaANelson/the_pivot" 6 | 7 | Orion, Jeffrey, Michael, Emily, Adam: 8 | repository: "https://github.com/mikedao/the_pivot" 9 | 10 | Kit, Bryce, Lydia, Chris: 11 | repository: "https://github.com/cluhring/the_pivot" 12 | -------------------------------------------------------------------------------- /scripts/Gemfile.lock: -------------------------------------------------------------------------------- 1 | GEM 2 | remote: https://rubygems.org/ 3 | specs: 4 | digitalocean (0.0.2) 5 | faraday 6 | faraday_middleware 7 | recursive-open-struct 8 | faraday (0.8.8) 9 | multipart-post (~> 1.2.0) 10 | faraday_middleware (0.9.0) 11 | faraday (>= 0.7.4, < 0.9) 12 | multipart-post (1.2.0) 13 | recursive-open-struct (0.4.5) 14 | 15 | PLATFORMS 16 | ruby 17 | 18 | DEPENDENCIES 19 | digitalocean 20 | -------------------------------------------------------------------------------- /1407/06_the_pivot/gallery.markdown: -------------------------------------------------------------------------------- 1 | # First Check In - 10/30 2 | 3 | ## Notes 4 | 5 | * Has lots of good small design elements 6 | * Seems to have a decent vision of where it's going 7 | * Feel like the team is communicating well 8 | 9 | ## Scoring 10 | 11 | ### Feature Delivery 12 | 13 | * Completion: 3 14 | * Organization: 3 15 | * Progress: 3 16 | 17 | #### Technical Quality 18 | 19 | * Test-Driven Development: 3 20 | * Code Quality: ? 21 | * User Experience: 2.5 22 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/maddux_john.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Maddux", 3 | :first_name => "John", 4 | :project_name => "Crafty", 5 | :project_description => "A site that lets you take your favorites from Etsy and create a poll that you can invite your friends to vote on.", 6 | :technologies => [], 7 | :integrations => ['etsy','facebook'] 8 | :repo => 'http://github.com/jemaddux/crafty', 9 | :heroku_account => 'jemaddux@gmail.com' 10 | } 11 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/steadman_laura.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Steadman", 3 | :first_name => "Laura", 4 | :project_name => "Trekkr", 5 | :project_description => "Take a virtual hike along the Pacific Crest Trail, via geo-tagged Instagram photos.", 6 | :technologies => ['MongoDB'], 7 | :integrations => ['Instagram', 'Mapbox/Leaflet'] 8 | :repo => 'http://github.com/thesteady/trekkr', 9 | :heroku_account => 'lauramsteadman@gmail.com' 10 | } 11 | -------------------------------------------------------------------------------- /1407/06_the_pivot/airlift.markdown: -------------------------------------------------------------------------------- 1 | # First Check In - 10/30 2 | 3 | ## Notes 4 | 5 | * Have the per-store browsing in place 6 | * Seems like good progress 7 | * For Tuesday going to build multi-order checkout with notifications to 8 | user and stores 9 | 10 | ## Scoring 11 | 12 | ### Feature Delivery 13 | 14 | * Completion: 3 15 | * Organization: 3 16 | * Progress: 3 17 | 18 | #### Technical Quality 19 | 20 | * Test-Driven Development: 2 21 | * Code Quality: ? 22 | * User Experience: 3 23 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/mastery_project/clear_status.rb: -------------------------------------------------------------------------------- 1 | { 2 | :developers => ["Kareem Grant"] 3 | :project_name => "ClearStatus", 4 | :project_description => "ClearStatus automates status reports, makes it easy for teams to communicate their progress throughout the organization, promotes transparent communication and cross-functional collaboration", 5 | :backend_technologies => ['postgres'], 6 | :frontend_technologies => ['jquery, angular'], 7 | :repo => 'http://github.com/kareemgrant/clear_status' 8 | } 9 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/tellez_jorge.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Téllez", 3 | :first_name => "Jorge", 4 | :project_name => "BandMatch", 5 | :project_description => "You pick a concert, make a plan, post it on Facebook, and other people can join your plan.", 6 | :technologies => ['memcache'], 7 | :integrations => ['SongKick', 'Facebook', 'Geocoder', 'Google Maps'], 8 | :repo => 'https://github.com/novohispano/bandmatch.git', 9 | :heroku_account => 'novohispano@gmail.com' 10 | } 11 | -------------------------------------------------------------------------------- /1409/05_dinner_dash/checkins/greg-viki-chase-konr: -------------------------------------------------------------------------------- 1 | Checkin with horace 2 | 3 | Progress 4 | - index looks ok; needs some minor html tweaks 5 | - schema is actually pretty flushed out 6 | - test coverage is ok 7 | 8 | Todo 9 | - slim down dem assets 10 | - los links! link the site together; make it so i can get to other places from the root 11 | - get signin working 12 | - clean up pending tests 13 | - lets start really zeroing in on the user stories 14 | - dont make git messes 15 | - read the logs 16 | -------------------------------------------------------------------------------- /1409/05_dinner_dash/checkins/danny-adam-david: -------------------------------------------------------------------------------- 1 | Checkin with: Horace 2 | Danny, Adam, David 3 | 4 | Done: 5 | - db schema coming together; many models are created and validations in place 6 | - user auth flow seems good 7 | - test coverage seems pretty good; tdd seems ok; need to get them updated to reflect new status quo 8 | 9 | todo: 10 | - seed data 11 | - build out frontend more 12 | - start looking at cart setup after Monday Cart class 13 | - biggest remaining data model chunk is orders -- would start looking at that soon 14 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/eliuk_jennifer.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Eliuk", 3 | :first_name => "Jennifer", 4 | :project_name => "Patient Intake", 5 | :project_description => "Patient intake forms and notifications for independent health care practitioners; to replace emailing PDFs for patients to fill out by hand and scan back", 6 | :technologies => ['hstore'], 7 | :integrations => ['twilio'] 8 | :repo => 'https://github.com/7maples/patient_intake.git', 9 | :heroku_account => 'jen7maples@gmail.com' 10 | } 11 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/maher_aimee.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "maher", 3 | :first_name => "aimee", 4 | :project_name => "Hunt for History", 5 | :project_description => "Using data.gov's historical landmark database, check into locations upon a trail of historical landmarks to get badges and compete against friends. ", 6 | :technologies => ['jQuery Mobile'], 7 | :integrations => ['Data.gov', 'foursquare'] 8 | :repo => 'http://github.com/aimzatron/caution_tape', 9 | :heroku_account => 'aimee@geekycheeks.com' 10 | } 11 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/sears_logan.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Sears", 3 | :first_name => "Logan", 4 | :project_name => "Re-Tap", 5 | :project_description => "A social beer recommendation platform. Login with Facebook, rate beers, and get recommendations based on what other users with similar tastes like. D3 will be used for data visualisation.", 6 | :technologies => ['Canvas/D3'], 7 | :integrations => ['Facebook'], 8 | :repo => 'http://github.com/diasporism/retap', 9 | :heroku_account => 'lsears322@gmail.com' 10 | } 11 | -------------------------------------------------------------------------------- /1409/05_dinner_dash/checkins/herbert_travis_tim_sam: -------------------------------------------------------------------------------- 1 | Checkin with: Horace 2 | 3 | 4 | Done: 5 | - schema starting to come together 6 | - user auth seems ok 7 | - frontend looking ok; seem like there are some pieces hanging out 8 | - need to trim unused bits out of frontend 9 | 10 | 11 | todo: 12 | - fix dem tests 13 | - migrate admin resources into admin namespace 14 | - cleanup unused templates 15 | - get menu_item schema in place 16 | - los links! link to the other parts of the site from root 17 | - would try to focus more on user stories and wrapping up loose ends 18 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/vanhekken_chase.md: -------------------------------------------------------------------------------- 1 | ### ApartCrime 2 | 3 | ### Pitch 4 | 5 | Overlay a heat map of crime statistics on a map with apartments. 6 | 7 | ### Problem 8 | 9 | People want to choose a safe location to live. Put the two types of data on the same map. 10 | 11 | ### Solution 12 | 13 | ApartCrime allows one to quickly view crime data in a visually easy way with a heat map, and apartment data, in the same place. 14 | 15 | ### Target Audience 16 | 17 | Young professionals in cities. 18 | 19 | ### Integrations 20 | 21 | * Google Maps 22 | * Crime API 23 | * Apartment API 24 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/mastery_project/enigmates.rb: -------------------------------------------------------------------------------- 1 | { 2 | developers: ["Geoffrey Schorkopf"], 3 | project_name: "Enigmates", 4 | project_description: "Enigmates sharpens your mind with daily puzzles you can solve simultaneously with Facebook/Twitter friends -- or with a complete stranger. Modes include 'versus' and 'co-op', and puzzle varieties include map challenges, sporcle-styled lists, and more.", 5 | backend_technologies: ['omniauth (twitter, facebook, google apps)'], 6 | frontend_technologies: ['faye', 'javascript', 'd3.js'], 7 | repo: 'http://github.com/gschorkopf/enigmates' 8 | } 9 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/tai_elaine.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Tai", 3 | :first_name => "Elaine", 4 | :project_name => "Hate Map", 5 | :project_description => "Interactive heat map of hate crimes that can be adjusted to show overall statistics in the United States or to more micro level by state. It can show information such as the type of crime, the race of the offender and the offended.", 6 | :technologies => ['Processing/Processing.js, Internationalization'], 7 | :integrations => ['Data.gov'] 8 | :repo => 'http://github.com/lalalainexd/', 9 | :heroku_account => 'lalalainexd@gmail.com' 10 | } 11 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/knight_chris.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Knight", 3 | :first_name => "Christopher", 4 | :project_name => "Hacktavism", 5 | :project_description => "An application where you can submit a link to an embeddable video relating to activism, and also a set of tags. This will take the submitted content and find charities and volunteer opportunities related to the video content's tags.", 6 | :technologies => ['VolunteerMatch.org, Charitynavigator.org'], 7 | :integrations => ['YouTube', 'Vimeo'] 8 | :repo => 'https://github.com/SerKnight/hactavism.git', 9 | :heroku_account => 'chrisknight.mail@gmail.com' 10 | } 11 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/jensen_alex.md: -------------------------------------------------------------------------------- 1 | ### FoodTrain 2 | 3 | ### Pitch 4 | 5 | Hook up with your friend groups to go out to lunch. Also follow other trains if you have no friends 6 | 7 | ### Problem 8 | 9 | Many people want to go for lunch with some other friends, but have a hard time deciding and gathering everyone up. 10 | 11 | ### Solution 12 | 13 | Food Train lets groups vote on places to go as well as sending out notifications when the train is about to leave. 14 | 15 | ### Target Audience 16 | 17 | People who need help planning group meals 18 | 19 | ### Integrations 20 | 21 | * Some texting thingy (twilio?) 22 | * Maybe some google maps 23 | * twitter 24 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/drummond_erin.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Drummond", 3 | :first_name => "Erin", 4 | :project_name => "Appointime", 5 | :project_description => "Online appointment scheduling that lets the business set their times weekly (and modify daily) and customers schedule appointments", 6 | :technologies => [], 7 | :integrations => ['Flickr', 'Yelp'] 8 | :repo => 'http://github.com/ebdrummond/appointime', 9 | :heroku_account => 'e.b.drummond@gmail.com', 10 | :needs_heroku_setup => true, 11 | :needs_workers => true, 12 | :needs_redis_to_go => true, 13 | :other_needs => ["a high five wherein both participants are seated"] 14 | } 15 | -------------------------------------------------------------------------------- /archive/gschool-0/reading/eloquent_ruby/rg2/group_7_notes.markdown: -------------------------------------------------------------------------------- 1 | ## RG2 Notes for Eloquent Ruby 2 | 3 | ### Short Methods (CH10) & Operators (CH11) & Equality (CH12) 4 | 5 | #### Key Ideas 6 | 7 | #### The Highlight 8 | 9 | #### The Lowlight 10 | 11 | ### Singletons (CH13) & Class Instance Variables (CH14) 12 | 13 | #### Key Ideas 14 | 15 | #### The Highlight 16 | 17 | #### The Lowlight 18 | 19 | ### Modules as Namespaces (CH15) & Mixins (CH16) 20 | 21 | #### Key Ideas 22 | 23 | #### The Highlight 24 | 25 | #### The Lowlight 26 | 27 | ### Blocks (CH17) & Execute Around (CH18) & Execute Later (CH19) 28 | 29 | #### Key Ideas 30 | 31 | #### The Highlight 32 | 33 | #### The Lowlight 34 | -------------------------------------------------------------------------------- /archive/gschool-0/reading/eloquent_ruby/rg2/group_8_notes.markdown: -------------------------------------------------------------------------------- 1 | ## RG2 Notes for Eloquent Ruby 2 | 3 | ### Short Methods (CH10) & Operators (CH11) & Equality (CH12) 4 | 5 | #### Key Ideas 6 | 7 | #### The Highlight 8 | 9 | #### The Lowlight 10 | 11 | ### Singletons (CH13) & Class Instance Variables (CH14) 12 | 13 | #### Key Ideas 14 | 15 | #### The Highlight 16 | 17 | #### The Lowlight 18 | 19 | ### Modules as Namespaces (CH15) & Mixins (CH16) 20 | 21 | #### Key Ideas 22 | 23 | #### The Highlight 24 | 25 | #### The Lowlight 26 | 27 | ### Blocks (CH17) & Execute Around (CH18) & Execute Later (CH19) 28 | 29 | #### Key Ideas 30 | 31 | #### The Highlight 32 | 33 | #### The Lowlight 34 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/larson_konr.md: -------------------------------------------------------------------------------- 1 | ### CloudBase 2 | 3 | ### Pitch 4 | 5 | A simple way to have all your cloud files in one place 6 | 7 | ### Problem 8 | 9 | Always having to log in to multiple sites to find are of you cloud storage files. 10 | 11 | ### Solution 12 | 13 | Integrate all the different cloud storage providers in to one location to be able to access, download and upload files in an easy to use interface. 14 | 15 | ### Target Audience 16 | 17 | Tech savvy web users that have the need to access there data where ever they have a data connection 18 | 19 | ### Integrations 20 | 21 | * Google 22 | * Google Drive 23 | * Dropbox 24 | * OneDrive 25 | * SugerSync 26 | * Box 27 | * Mega 28 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/lastname_firstname.rb: -------------------------------------------------------------------------------- 1 | # 1) Create a file like this with your own lastname_firstname.rb 2 | # 2) Fill in the details 3 | # 3) Submit a pull request 4 | 5 | { 6 | :last_name => "Your Last Name", 7 | :first_name => "Your First Name", 8 | :project_name => "The Project Name", 9 | :project_description => "One paragraph about what the app will do and why", 10 | :technologies => ['riak'], 11 | :integrations => ['github', 'facebook'] 12 | :repo => 'http://github.com/username/repo_name', 13 | :heroku_account => 'you@gmail.com', 14 | :needs_heroku_setup => false, 15 | :needs_workers => false, 16 | :needs_redis_to_go => false, 17 | :other_needs => ["none"] 18 | } 19 | -------------------------------------------------------------------------------- /1409/04_clone_wars/checkins/david-sam-alex: -------------------------------------------------------------------------------- 1 | Checkin with: Josh Cheek 2 | David Sam Alex 3 | 4 | fix asssets by prepending a "/" 5 | 6 | Advice: merge multiple times a day 7 | 8 | users: 9 | people visiting the site 10 | admin wanting to update the price 11 | 12 | To have value to the admin: 13 | Populate data on the view (/shop) from the database 14 | admin page 15 | form to edit the data (means an endpoint to render the form) 16 | submits, leading to db updates (means an endpoint to take the data and toss it into the db) 17 | auth of some sort 18 | put auth on admin page 19 | figure out how to connect the app to the Heroku db 20 | ``` 21 | $ heroku run bash 22 | $ echo $DATABASE_URL 23 | ``` 24 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/tan_doan.markdown: -------------------------------------------------------------------------------- 1 | ## Expectations 2 | 3 | ### Need to Have All 4 | 5 | + You must use an external OAuth provider to authenticate users 6 | You must filter data appropriately in both the web and API based on authorization rules 7 | - You must make use of a Virtual Private Server to host your application 8 | - Make use of background workers for all appropriate tasks 9 | - Send notifications to users over email/SMS/Twitter 10 | 11 | ## Scores 12 | 13 | ### Feature Delivery 14 | * Feature Completion: 3 15 | * Project Completion: 2.5 16 | * User Experience: 3 17 | 18 | ### Technical Quality 19 | 20 | * Organization: 2 21 | * Test-Driven Development: 2.5 22 | * Code Quality: 2.5 23 | 24 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/garreau_marc.markdown: -------------------------------------------------------------------------------- 1 | # Career Crumbs 2 | 3 | ## Expectations 4 | 5 | ### Need to Have All 6 | 7 | + You must use an external OAuth provider to authenticate users 8 | You must filter data appropriately in both the web and API based on authorization rules 9 | - You must make use of a Virtual Private Server to host your application 10 | - Make use of background workers for all appropriate tasks 11 | - Send notifications to users over email/SMS/Twitter 12 | 13 | ## Scores 14 | 15 | ### Feature Delivery 16 | * Feature Completion: 2.5 17 | * Project Completion: 3 18 | * User Experience: 2.5 19 | 20 | ### Technical Quality 21 | 22 | * Organization: 3 23 | * Test-Driven Development: 2 24 | * Code Quality: 3 25 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/blackwell_paul.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Blackwell", 3 | :first_name => "Paul", 4 | :project_name => "Harvesting Tomatoes", 5 | :project_description => "I'm creating an application that integrates pomodoros with the harvest app. 6 | I guess it will also be integrating google calendar. A big problem with Harvest is that you forget that you 7 | have a timer going, so I want to connect it with pomodoros so you don't forget what you're working on. It will 8 | also make time tracking more accurate.", 9 | :technologies => ['node.js'], 10 | :integrations => ['google calendar', 'harvest'] 11 | :repo => 'http://github.com/pnblackwell/harvesting_tomatoes', 12 | :heroku_account => 'pnblackwell@gmail.com' 13 | } -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/rogers_shane: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Rogers", 3 | :first_name => "Shane", 4 | :project_name => "Socrada", 5 | :project_description => "Socrada will visialize your social connections so that you can strategize your networking. Using Twitter relationships initially, Socrada will weight the ease of connectivity to someone in the network and provide the MER(maximum efficient route) to connecting with that person.", 6 | :technologies => ['d3, neo4j'], 7 | :integrations => ['twitter'] 8 | :repo => 'http://github.com/phoenixbox/socrada', 9 | :heroku_account => 'rogerssh@gmail.com' 10 | :needs_heroku_setup => true, 11 | :needs_workers => true, 12 | :needs_redis_to_go => true, 13 | :other_needs => ["neo4j"] 14 | } 15 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/tim_proctor.markdown: -------------------------------------------------------------------------------- 1 | # ChargeIt 2 | 3 | ## Expectations 4 | 5 | ### Need to Have All 6 | 7 | + You must use an external OAuth provider to authenticate users 8 | You must filter data appropriately in both the web and API based on authorization rules 9 | - You must make use of a Virtual Private Server to host your application 10 | - Make use of background workers for all appropriate tasks 11 | - Send notifications to users over email/SMS/Twitter 12 | 13 | ## Scores 14 | 15 | ### Feature Delivery 16 | 17 | * Feature Completion: 3 18 | * Project Completion: 2 19 | * User Experience: 2 20 | 21 | ### Technical Quality 22 | 23 | * Organization: 1 24 | * Test-Driven Development: 0 25 | * Code Quality: 2 26 | 27 | ## Demo: Skip 28 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/mastery_project/daughter_of_new_leaf_massage.rb: -------------------------------------------------------------------------------- 1 | { 2 | :developers => ["Erin Drummond"] 3 | :project_name => "Daughter of New Leaf Massage", 4 | :project_description => "I want to build on the New Leaf Massage site I worked on for my individual project. There's a lot that I'm still working on, but for the next week and a half I want to focus on 1) ability to schedule a recurring appointment (e.g. every Tuesday at 10am), 2) online payments, 3) her updated appointment times (they've shifted since I built this), and 4) if there is time, a revamped admin dashboard to view her upcoming schedule.", 5 | :backend_technologies => ['integration with Paypal'], 6 | :frontend_technologies => ['Javascript'] 7 | :repo => 'http://github.com/ebdrummond/new_leaf' 8 | } -------------------------------------------------------------------------------- /archive/gschool-0/projects/mastery_project/socrada: -------------------------------------------------------------------------------- 1 | { 2 | :developers => ["Shane Rogers 1",] 3 | :project_name => "Socrada", 4 | :project_description => "There is currently no ability to visualise a 'stepping stone' map of connections to people within a social network. If I want to connect with someone outside of my immediate social network I should be able to plot the necessary connections to make in order to get a legitimate introduction. Socrada will pull in social media connections and attempt to weight the relationship value between two parties to facilitate a node graph search which will yield the most efficient route to connection.", 5 | :backend_technologies => ['neo4j'], 6 | :frontend_technologies => ['D3'] 7 | :repo => 'http://github.com/phoenixbox/socrada2' 8 | } 9 | -------------------------------------------------------------------------------- /1407/06_the_pivot/fresh_threads.markdown: -------------------------------------------------------------------------------- 1 | # First Check In - 10/30 2 | 3 | ## Notes 4 | 5 | * Goals for today: sketch out store, item pages - up to cart 6 | * Can browse individual stores, see items, view items 7 | * Categories are global -- want to have global and per-store available 8 | * For Tuesday, have full user browsing, add to cart, checkout, generate multiple orders, send notifications to customer & store owners 9 | * Lots of pending tests for future features, 92 total, 42 pending, 91% covereage, make sure to test at multiple layers 10 | 11 | ## Scoring 12 | 13 | ### Feature Delivery 14 | 15 | * Completion: 3 16 | * Organization: 3 17 | * Progress: 3 18 | 19 | #### Technical Quality 20 | 21 | * Test-Driven Development: 3 22 | * Code Quality: ? 23 | * User Experience: 3 24 | -------------------------------------------------------------------------------- /blogging/2014-09-26.markdown: -------------------------------------------------------------------------------- 1 | Add your post's production URL below: 2 | 3 | ## The Pivot Project Posts 4 | 5 | * TravelHome: 6 | * Airlift: 7 | * EmployMe: 8 | * Keevahh: 9 | 10 | ## Individual Posts 11 | 12 | * Aaron Paul Wortham: 13 | * Adam Smith: 14 | * Alex Jensen: 15 | * Cara Dennis: 16 | * Chandra Carney: 17 | * Chase van Hekken: 18 | * Christopher Bynum: 19 | * Danny Glunz: 20 | * David Bayendor: 21 | * Glen Egbert: 22 | * Gregory Narajka: 23 | * Herbert Joseph: 24 | * Ian Andersen: 25 | * Jessica Goulding: 26 | * Jim Sutton: 27 | * Kalah Cheek: 28 | * Kate Lane: 29 | * Kavita Sachdeva: 30 | * Konr Josef Laron: 31 | * Luke Aiken: 32 | * Rolando Navarrete: 33 | * Sam Kuhlmann: 34 | * Sara Simon: 35 | * Timothy Mee: 36 | * Travis Yoder: 37 | * Victoria Harrod: 38 | * Zachary Routhier: 39 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/battos_phil.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Battos", 3 | :first_name => "Phil", 4 | :project_name => "Cache Map", 5 | :project_description => "The main purpose of this app will be to take search results related to clues in the Fenn Treasure Hunt, find associated place names from USGS geonames database, and map all related results using Google Maps API. The search results can be used by the user to find likely locations for the treasure. Aggregated search results can be analyzed by developers to study how users are interpreting the clues and where they are searching.", 6 | :technologies => ['Raphael.js'], 7 | :integrations => ['Google Maps', 'Data.gov'] 8 | :repo => 'http://github.com/username/repo_name', 9 | :heroku_account => 'philbattos@gmail.com' 10 | } -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/grant_kareem.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Grant", 3 | :first_name => "Kareem", 4 | :project_name => "shot_visualizer", 5 | :project_description => "ShotVisualizer takes NBA shooting location data and provide users with a visual way to analyze a team's or individual's shooting performance from specific areas of the court. Visual shot location data has the power to reveal the 'hidden' statistics of the game that are not detailed in traditional box scores. ShotVisualizer has a variety of uses which include scouting, player development, player acquisition and research." 6 | :technologies => ['MongoDB'], 7 | :integrations => ['Sports(NBA.com, etc.)'] 8 | :repo => 'http://github.com/kareemgrant/shot_visualizer', 9 | :heroku_account => 'kareem@getuserwise.com' 10 | } 11 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/garcia_danny.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Garcia", 3 | :first_name => "Danny", 4 | :project_name => "BizStartr", 5 | :project_description => "BizStartr integrates with one of the SBA's APIs to provide entrepreneurs with information about federal, state, and local licences and permits required to start a business in a certain state. BizStarts takes advantage of D3.js to provide a visualization of the United States, allowing users to easily choose a state and quickly get access to a myriad of information about starting a business in a certain state.", 6 | :technologies => ['D3'], 7 | :integrations => ['sba.gov'] 8 | :repo => 'https://github.com/danny-g/biz_startr', 9 | :heroku_account => 'dannygarcia.me@gmail.com', 10 | :url => 'http://bizstartr.herokuapp.com/' 11 | } 12 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/harrod_viki.md: -------------------------------------------------------------------------------- 1 | ### Funding Congress 2 | 3 | ### Pitch 4 | 5 | A simple look-up for a list of your Congress people and their top funding sources 6 | 7 | ### Problem 8 | 9 | Most people know that the funding for politicians heavily influences their decision 10 | making, but that information isn't always easy to find. Without an easy way to 11 | access that information, voters who might otherwise be more involved feel like 12 | they cannot make informed voting decisions. 13 | 14 | ### Solution 15 | 16 | A website that allows a user to look up their Congress people and get a list of 17 | their top funding sources. 18 | 19 | ### Target Audience 20 | 21 | Registered voters. 22 | 23 | ### Integrations 24 | 25 | * Facebook 26 | * Sunlight Foundation's Congress API and Influence Explorer API 27 | * Mandrill for email 28 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/tim_proctor.markdown: -------------------------------------------------------------------------------- 1 | ## Idea 5: 2 | 3 | ### ParkIt 4 | 5 | SELECTED! 6 | 7 | #### Pitch 8 | 9 | Wouldn't be great if you could get the latest info and reviews on the best 10 | places to park? 11 | 12 | #### Description 13 | 14 | ParkIt gives subscribers info on parking lots and spaces in and around Denver. 15 | The best part of the site is the up-to-date comments and ratings from subscribers. 16 | Earn badges and points when information is "agreed" by other subscribers. 17 | This is the Yelp of the parking world and we all need a place to park at some 18 | point. 19 | 20 | #### Target Audience 21 | 22 | Drivers. People with available parking. 23 | 24 | #### Integrations 25 | 26 | data: http://data.opencolorado.org/dataset/city-and-county-of-denver-parking-facilities 27 | OAuth: Twitter 28 | Google API 29 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/schorkopf_geoffrey.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Schorkopf", 3 | :first_name => "Geoffrey", 4 | :project_name => "Eldoorado", 5 | :project_description => "Eldoorado is a business intellegence and API for door scan data in the Galvanize space. How many people come in on Friday's? What patterns can we derive from this information?" 6 | :technologies => ['d3'], 7 | :integrations => ['eldoorado'] 8 | :repo => ['http://www.github.com/gschorkopf/eldoorado_api', 9 | 'http://www.github.com/gschorkopf/eldoorado', 10 | 'http://www.github.com/gschorkopf/eldoorado', 11 | 'http://www.github.com/gschorkopf/eldoorado'] 12 | :heroku_account => 'gschorkopf@gmail.com', 13 | :needs_heroku_setup => false, 14 | :needs_workers => false, 15 | :needs_redis_to_go => false, 16 | } 17 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/mee_daniel.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Mee", 3 | :first_name => "Daniel", 4 | :project_name => "Songify", 5 | :project_description => "This app will take in a block of text and turn it into a song. Specifically, it will break the text into lines of a specific number of syllables and rhyme the last words of every two lines. Uses for this app will be entertainment/sillyness and education. The education value will come from taking information and translating it into a more easily memorizable form...song. Users will have the option of signing into their instagram accounts to incorporate personal photos as album artwork.", 6 | :technologies => ['elasticsearch'], 7 | :integrations => ['instagram'] 8 | :repo => 'http://github.com/danmee10/text_to_song', 9 | :heroku_account => 'danmee10@gmail.com' 10 | } 11 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/joseph_herbert.md: -------------------------------------------------------------------------------- 1 | # Peel The Apple 2 | 3 | ### Pitch 4 | 5 | Compiling compelling, interactive story maps meant to go in-depth on the occurrences in NYC based on data from reliable sources. 6 | 7 | ### Problem 8 | 9 | Young people (myself included) are often oblivious to the information these datasets can convey, even NYC citizenry. There are many disparities, problems, and interesting facts that are missed out on because of this. 10 | 11 | ### Solution 12 | 13 | Using "Peel The Apple", users will be able to see this data in an understandable and interactive format allowing the spread of this information and more people being informed. 14 | 15 | ### Target Audience 16 | 17 | Geared more towards younger audiences, 17-25. 18 | 19 | ### Integrations 20 | 21 | * OAuth (FB + Twitter) 22 | * Leaflet 23 | * Mapbox.js 24 | * Google Streetview 25 | * Socrata 26 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/jonmichael.markdown: -------------------------------------------------------------------------------- 1 | ## Jonmichael - StreamWatcher 2 | 3 | * Reads data from an API and provides a dashboard 4 | * Production deployment is a bit shaky 5 | * Has some interesting features 6 | * Good technical components 7 | 8 | ### Need to Have 9 | 10 | + You must use an external OAuth provider to authenticate users 11 | + You must filter data appropriately in both the web and API based on authorization rules 12 | + You must make use of a Virtual Private Server to host your application 13 | + Make use of background workers for all appropriate tasks 14 | + Send notifications to users over email/SMS/Twitter 15 | 16 | ### Nice to Have 17 | 18 | + Automated deployment 19 | 20 | ### Scoring 21 | 22 | * Features: 3 23 | * Project Completion: 2 24 | * UX: 2 25 | 26 | ### Quality 27 | 28 | * Management: 1 29 | * Testing: 1 30 | * Code Quality: 3 Ruby, 2 JavaScript 31 | 32 | Demo: Yes 33 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/komlo_chelsea.rb: -------------------------------------------------------------------------------- 1 | # 1) Create a file like this with your own lastname_firstname.rb 2 | # 2) Fill in the details 3 | # 3) Submit a pull request 4 | 5 | { 6 | :last_name => "Komlo", 7 | :first_name => "Chelsea", 8 | :project_name => "Coordinating Groups in Natural Disasters", 9 | :project_description => "This application allows for group coordination and tracking individuals in the wake of natural disasters. Using a text-based interface, individuals will be able to text their location and receive directions to the closest available center for relief.", 10 | :technologies => ['CouchDB',], 11 | :integrations => ['google maps'] 12 | :repo => 'https://github.com/chelseakomlo/disaster_relief', 13 | :heroku_account => 'chelsea.komlo@gmail.com', 14 | :needs_heroku_setup => true, 15 | :needs_workers => true, 16 | :needs_redis_to_go => true, 17 | :other_needs => ["none"] 18 | } 19 | -------------------------------------------------------------------------------- /1407/05_dinner_dash/dinner_dash_submissions.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | Ian, Jessica, Luke: 3 | repository: 4 | setup_notes: "" 5 | instructor_evaluation: 6 | notes: "" 7 | rubric: 8 | Feature Completeness: 4 9 | Views: 4 10 | Controllers: 3 11 | Models: 4 12 | TDD: 3 13 | Usability: 4 14 | Sara, Rolando, Jim: 15 | repository: 16 | setup_notes: "" 17 | instructor_evaluation: 18 | notes: "" 19 | rubric: 20 | Feature Completeness: 3.5 21 | Views: 3 22 | Controllers: 2.5 23 | Models: 3 24 | TDD: 2.5 25 | Usability: 4 26 | Kavita, Glen, Aaron: 27 | repository: 28 | setup_notes: "" 29 | instructor_evaluation: 30 | notes: "" 31 | rubric: 32 | Feature Completeness: 3 33 | Views: 4 34 | Controllers: 4 35 | Models: 4 36 | TDD: 3 37 | Usability: 2.5 38 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/hilary_denton.markdown: -------------------------------------------------------------------------------- 1 | # Walkabout 2 | 3 | * Some rough edges 4 | * Selenium tests are good 5 | * 6 | 7 | ## Expectations 8 | 9 | ### Need to Have All 10 | 11 | + You must use an external OAuth provider to authenticate users 12 | + You must filter data appropriately in both the web and API based on authorization rules 13 | + You must make use of a Virtual Private Server to host your application 14 | - Make use of background workers for all appropriate tasks 15 | + Send notifications to users over email/SMS/Twitter 16 | 17 | ### Nice to Have 18 | 19 | ? Your application must accept uploads of some user images - kinda 20 | 21 | ## Scores 22 | 23 | ### Feature Delivery 24 | 25 | * Feature Completion: 3 26 | * Project Completion: 2.5 27 | * User Experience: 2 28 | 29 | ### Technical Quality 30 | 31 | * Organization: 2 32 | * Test-Driven Development: 2 33 | * Code Quality: 3 34 | 35 | ### Demo: Yes 36 | -------------------------------------------------------------------------------- /1409/04_clone_wars/checkins/herbert-danny-kate: -------------------------------------------------------------------------------- 1 | Checkin with: Josh Cheek 2 | Herbert, Danny, Kate 3 | 4 | To do: 5 | everybody do this first 6 | merge all relevant branches 7 | fix conflicts as appropriate (e.g. one kind of auth ;) 8 | delete merged branches (git push origin :branch-name) 9 | 10 | 2 people do 11 | in conjunction 12 | Fill in values in the views from database 13 | When submitting the forms from the admin side, save them into the database 14 | 15 | 1 person gets it on Heroku 16 | You'll have to do something like this: 17 | development do 18 | set :database, Sequel.sqlite('development.db') 19 | end 20 | production do 21 | credentials = ?? 22 | set :database, Sequel.postgresql(credentials) # or maybe url 23 | end 24 | How to get credentials? 25 | ``` 26 | $ heroku run bash 27 | $ echo $DATABASE_URL 28 | ``` 29 | figure out how to parse that url 30 | -------------------------------------------------------------------------------- /1410/04_ideabox/ideabox_submissions.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | Rich Shea: 3 | repository: https://github.com/rshea303/idea_box 4 | Laura Whalin: 5 | repository: 6 | Jeffrey Wan: 7 | repository: 8 | Bryce Holcomb: 9 | repository: 10 | Nathan Owsiany: 11 | repository: 12 | Emily Berkeley: 13 | repository: https://github.com/EmilyMB/ideabox2 14 | Michael Dao: 15 | repository: https://github.com/mikedao/ideabox 16 | Orion Osborn: 17 | repository: https://github.com/oorion/idea_box.git 18 | Bhargavi Satpathy: 19 | repository: 20 | Krista A Nelson: 21 | repository: 22 | Brandon Mrsny: 23 | repository: 24 | Scott Crawford: 25 | repository: https://github.com/scottcrawford03/ideabox 26 | Kit Pearson: 27 | repository: 28 | Chris Luhring: 29 | repository: 30 | Dustin Gault: 31 | repository: 32 | Lydia Shafer:https://github.com/Lydias303/IdeaBox 33 | repository: 34 | Alexandra Robinson: 35 | repository: 36 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/glunz_danny.md: -------------------------------------------------------------------------------- 1 | ### MoodRing 2 | 3 | ### Pitch 4 | 5 | Code Climate for analyzing the mood of your open-source project based on 6 | sentiment analysis of commit messages. 7 | 8 | ### Problem 9 | 10 | Collaboration and programming can both be very stressful endeavours. It can be 11 | difficult to manage and keep contributors coming back to an open-source project. 12 | 13 | ### Solution 14 | 15 | In order to entice new developers and retain current ones, it would be 16 | beneficial to display the current morale of a project. 17 | 18 | ### Target Audience 19 | 20 | Maintainers of open-source projects, businesses interested in quantifying 21 | developer happiness, and curious coders. 22 | 23 | ### Integrations 24 | 25 | * GitHub, bitbucket, etc. 26 | * One of the many available [nlp APIs](http://textblob.readthedocs.org/en/dev/) 27 | * Potentially other repo analysis tools to draw comparisons (i.e. CodeClimate to 28 | compare quality of code with happiness) 29 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/carney_chandra.md: -------------------------------------------------------------------------------- 1 | ### ArtR (WIP) 2 | 3 | ### Pitch 4 | 5 | ArtR is an app that acts like Tinder for artists and artworks. If a user likes more than 3 artworks by an artist, they subscribe to that artist. The new artworks shown would come from related results. 6 | 7 | ### Problem 8 | 9 | People interested in new artworks and artists don't have a way to interact with art in a fun setting. This would provide an interactive way for students to find and keep up with artists similar to those they currently like. 10 | 11 | ### Solution 12 | 13 | This app provides artist/artwork recommendations based upon artists previously liked and narrows down preferences based on previously liked art. 14 | 15 | ### Target Audience 16 | 17 | Art and art history students and buffs who are interested in finding more artwork and keeping up to date on contemporary art solutions. 18 | 19 | ### Integrations 20 | 21 | * Twitter OAuth 22 | * What API will you use? Artsy API 23 | * Twilio to recieve text messages or Mandrill for email 24 | -------------------------------------------------------------------------------- /scripts/provisioner_do.rb: -------------------------------------------------------------------------------- 1 | require 'bundler/setup' 2 | require 'digitalocean' 3 | 4 | module Provisioner 5 | class DO 6 | Digitalocean.client_id = ENV['digital_ocean_client_id'] 7 | Digitalocean.api_key = ENV['digital_ocean_api_key'] 8 | 9 | unless Digitalocean.client_id && Digitalocean.api_key 10 | raise "Need keys defined in ENV" 11 | end 12 | 13 | def size 14 | @size ||= Digitalocean::Size.all.sizes.detect{|s| s.name == "4GB"} 15 | end 16 | 17 | def image 18 | @image ||= Digitalocean::Image.all.images.detect{|i| i.slug == "ubuntu-14-04-x64"} 19 | end 20 | 21 | def region 22 | @region ||= Digitalocean::Region.all.regions.detect{|r| r.slug == "nyc1"} 23 | end 24 | 25 | def provision_server(name) 26 | Digitalocean::Droplet.create({:name => name, 27 | :size_id => size.id, 28 | :image_id => image.id, 29 | :region_id => region.id}) 30 | end 31 | end 32 | end 33 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/mastery_project/artistic_streets.rb: -------------------------------------------------------------------------------- 1 | { 2 | :developers => ["Bradley Sheehan", "Laura Steadman"], 3 | :project_name => "Artistic Streets", 4 | :project_description => "Uncover a new sense of place by discovering public art in your area. This app let's people discover and document public art pieces in their area and around the world. Goals this time around are to integrate with instagram, introduce the concept of administrators that can review submissions, create a better mobile experience (which is the primary use case), and to try and prevent duplicate and inappropriate submissions by providing functionality that will give users more ownership of the map (i.e. user can subscribe to a zipcode and get an email or text message when a new art piece has been submitted. The notified user can then be a 'guardian' of the map by flagging duplicate or inappropriate submissions).", 5 | :backend_technologies => ['riak', 'twilio'], 6 | :frontend_technologies => ['D3'], 7 | :repo => 'http://github.com/bradpsheehan/artistic_streets' 8 | } 9 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/narajka_greg.md: -------------------------------------------------------------------------------- 1 | ### Better Reads 2 | 3 | ### Pitch 4 | 5 | Better Reads generates book ratings and recommendations based on the interests of people with whom the user is more likely to align. 6 | 7 | ### Problem 8 | 9 | Aggregate ratings from large numbers of people are useful when shopping for a consumer product or deciding on a restaurant for dinner, but taste in books is idiosyncratic. The judgment of the right person is often more valuable than the thousand practically anonymous reviews you normally find on GoodReads. 10 | 11 | ### Solution 12 | 13 | This app will focus on matching the user with other like-minded users and suggest books based the latter's interests. I'd also very much like to generate alternate ratings, but that depends on the limitations of the API (current one request per second limit). 14 | 15 | ### Target Audience 16 | 17 | People with fairly settled taste in books. 18 | 19 | ### Integrations 20 | 21 | * GoodReads OAuth if possible, otherwise Facebook OAuth (which Goodreads already uses) 22 | * GoodReads API 23 | -------------------------------------------------------------------------------- /archive/gschool-0/reading/eloquent_ruby/rg2/README.markdown: -------------------------------------------------------------------------------- 1 | ## Eloquent Ruby - Reading Group 2 2 | 3 | For this exercise: 4 | 5 | 1. Edit your group's `group_x_notes.markdown` file 6 | 2. Fill in your responses 7 | 3. Submit one or more pull requests 8 | 9 | The responses should be in thoughtful paragraphs and make use of markdown's formatting for `inline code`, **bold**/*italic*, etc. 10 | 11 | Consider the following questions as guides to help you build a strong response: 12 | 13 | #### Key Ideas 14 | 15 | * If you were distilling the chapters down to one page, what would get included? 16 | * When are the techniques useful / how do you recognize situations to use them? 17 | 18 | #### The Highlight 19 | 20 | * What topic made you say "OH!"? 21 | * What will save you work in the future? 22 | * What didn't make sense before but now clicked? 23 | 24 | #### The Lowlight 25 | 26 | * What's still confusing? 27 | * Was there a subject where you understood the code but not why you'd want to use it? 28 | * Did something stand out as particularly hackish, strange, or ugly? 29 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/anderson_blair.rb: -------------------------------------------------------------------------------- 1 | # 1) Create a file like this with your own lastname_firstname.rb 2 | # 2) Fill in the details 3 | # 3) Submit a pull request 4 | 5 | { 6 | :last_name => "Anderson", 7 | :first_name => "Blair", 8 | :project_name => "ShareMore", 9 | :project_description => "ShareMore is a website that makes it easy for people to share their long-form thoughts through a simple interface or secure API. Users first authenticate with twitter, then they write articles on the website or POST an article body through our API. The article will be visible to people with the link, the summary and link will be republished on their twitter feed. The users public feed is visible at example.com/twitterusername.", 10 | :technologies => ['App API','API Gem'], 11 | :integrations => ['twitter'] 12 | :repo => 'https://github.com/blairanderson/share-more', 13 | :heroku_account => 'blair81@gmail.com' 14 | :needs_heroku_setup => true, 15 | :needs_workers => true, 16 | :needs_redis_to_go => true, 17 | :other_needs => ["none"] 18 | } 19 | -------------------------------------------------------------------------------- /1412/challenges/cryptographer.markdown: -------------------------------------------------------------------------------- 1 | ## Cryptographer 2 | 3 | * Challenge: https://github.com/turingschool/challenges/blob/master/cryptographer.markdown 4 | * Assigned: 12/18/14 5 | * Due: 12/19/14 6 | 7 | ### Submissions 8 | 9 | * Andrew Overby: 10 | * [Austin Wood](https://gist.github.com/indiesquidge/efa92118aac1f99af611) 11 | * Charles Valentino Espinoza: 12 | * DJ Greenfield: https://github.com/AllPurposeName/encryption2 13 | * David E Maurer: 14 | * Edward McCarthy: https://gist.github.com/mcshakes/ef86e532a76a48269a30 15 | * Fred Block: 16 | * Jack Yeh: 17 | * Jeffrey Gu: 18 | * Juan Manuel Navarro: https://github.com/gomav/ROT-13_Encrypter_Decrypter_Assignment 19 | * Kyle Henson: 20 | * Kyra Weber: 21 | * Lori Culberson:https://gist.github.com/loriculberson/56351f877496d7752d6d 22 | * Markus Olsen: 23 | * Miriam Moser: https://gist.github.com/mirjoy/7a18515b14ada940f626 24 | * Paul Grever: 25 | * Stanley Siudzinski: https://github.com/stanleyjsdz/encryptor 26 | * Teresa Finn: 27 | * Thomas Randell: 28 | * Trey Tomlinson: https://gist.github.com/treyyyy/2d4b2048dcee66f5499a 29 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/mejia_josh.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "mejia", 3 | :first_name => "josh", 4 | :project_name => "sparklr", 5 | :project_description => "'Do you have a lot of ideas but no clue how to organize them? Or maybe ideas come to you and by the time you have a chance to record them, you've forgotten? Enter the Spark File. As Alex Hillman explains, this tool doesn't just capture half-baked ideas—it helps you turn small concepts into great things.' -lifehacker. Sparklr is an online app that parses spark files saved in txt format and saves individual lines as items in a database. It integrates with Dropbox to allow you to continue to add content even if you aren't currently online. More info here: http://lifehacker.com/5941997/defrag-your-brain-with-a-spark-file", 6 | :technologies => ['riak'], 7 | :integrations => ['dropbox', 'sendgrid'], 8 | :repo => 'http://github.com/jmejia/sparklr', 9 | :heroku_account => 'joshua.mejia@gmail.com', 10 | :needs_heroku_setup => true, 11 | :needs_workers => true, 12 | :needs_redis_to_go => true, 13 | :other_needs => ["none"] 14 | } 15 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/yoder_travis.md: -------------------------------------------------------------------------------- 1 | ### MV Listr 2 | 3 | ### Pitch 4 | 5 | MV Listr is like Evernote for movie recommendations. Recommendations come from you via text message 6 | and are organized on MV Listr with beautiful information from IMDB. 7 | 8 | ### Problem 9 | 10 | Friends and family will talk about movies that you must see, but it's difficult to have a good place 11 | see those recommendations. Note taking apps take too long to launch, are too hard to find among the 12 | hundreds of apps located on your phone and get easily cluttered. 13 | 14 | ### Solution 15 | 16 | MV Listr will accept input from text message that can be the title of movie, series or even episode of 17 | a series. Your text messaging app usually the easiest for you to access on your phone and even integrates 18 | with most dictating apps like Siri and Google Now. This makes it very quick to send recommendations to 19 | MV Listr. 20 | 21 | ### Target Audience 22 | 23 | Movie buffs, people who like lists. 24 | 25 | ### Integrations 26 | 27 | * Twitter OAuth 28 | * www.omdbapi.com OMDB API 29 | * Twilio to receive text messages 30 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/mee_tim.md: -------------------------------------------------------------------------------- 1 | ### SnowMaps 2 | 3 | ### Pitch 4 | 5 | Colorado has a great selection of skiing and snow is not hard to come by. But, unfortunately, everytime I go skiing I must search multiple websites to find where the best snow is. If only there were a way to get the snow report for every moutain near me with one click. Snow Maps will bring the resort information you want to one page. 6 | 7 | ### Problem 8 | 9 | The Epic Pass gives its owner the choice between unlimited access for 12 mountains in the U.S. This means navigating multiple resort websites to find the current snow reports, which is wasted time that could have been spent out on the hill. 10 | 11 | ### Solution 12 | 13 | Create an app that allows anyone to get the snow report and trail/lift status from resort sites as well as current weather details displayed on one page. 14 | 15 | ### Target Audience 16 | 17 | A skier/rider that owns a season pass or a house close to multiple mountains and enjoys skiing all sections of the mounatain 18 | 19 | ### Integrations 20 | 21 | * What OAuth provider makes sense for this audience? 22 | * Weather.com api 23 | * Nokogiri to parse html 24 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/robert_gu.markdown: -------------------------------------------------------------------------------- 1 | ## Robert - Umbrella 2 | 3 | * Functionality and UX are ok 4 | * Background workers concepts need detangling 5 | * 6 | 7 | ### Need to Have All 8 | 9 | + You must use an external OAuth provider to authenticate users 10 | + You must filter data appropriately in both the web and API based on authorization rules 11 | - You must make use of a Virtual Private Server to host your application 12 | + Make use of background workers for all appropriate tasks 13 | + Send notifications to users over email/SMS/Twitter 14 | 15 | ### Nice to Have 16 | 17 | - You must automate the deployment of your application to a single command 18 | - Your application must accept uploads of some user images 19 | - Your application must manipulate those images to suit the layout/style of the app itself 20 | - Receive some form of content from users via email 21 | 22 | ### Scores 23 | 24 | #### Feature Delivery 25 | 26 | * Feature Completion: 3 27 | * Project Completion: 2.5 28 | * User Experience: 2 29 | 30 | #### Technical Quality 31 | 32 | * Organization: 2 33 | * Test-Driven Development: 2 34 | * Code Quality: 2 35 | 36 | #### Demo: yeah...if the texts are coming through 37 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/bayendor_david.md: -------------------------------------------------------------------------------- 1 | ### A Thousand Words 2 | 3 | ### Pitch 4 | 5 | A picture is worth a thousand words 6 | 7 | ### Problem 8 | 9 | Twitter limits users to only 140 characters, so tweets tends to be either laconic or links to other items. On the plus side, tweets are very much a real time phenomenom, and Twitter trends can be very revealing during emerging stories of local or national interest. 10 | 11 | Instagram provides a quick an convenient way to express artistic impressions via it's various photographic filters and share them quickly on the instagram stream. 12 | 13 | It would be interesting to discover what it would be like to find relationships between emerging twitter trends and the pictures that may (or may not) be trending on instagram simultaenously. 14 | 15 | ### Solution 16 | 17 | Integrate twitter trending feeds and geolocation with pictures occurring from the same region, or with similar hashtags. 18 | 19 | ### Target Audience 20 | 21 | Social media users, of moderate means in developed countries with access to the web who have accounts on one or both services. 22 | 23 | ### Integrations 24 | 25 | * OAuth 26 | * Twitter 27 | * Instagram 28 | * GeoLocation API of somekind 29 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/kuhlmann_sam.md: -------------------------------------------------------------------------------- 1 | ### Salad Days 2 | 3 | ### Pitch 4 | 5 | A resource for finding fresh and local food sources in your area. 6 | 7 | ### Problem 8 | 9 | I need a single reference point for finding locally sourced food in my area. Additionally, I grow a lot of food and would love a way to trade and share with people in my community. 10 | 11 | ### Solution 12 | 13 | This solution will be a directory of fresh food available in your area, from farmer's markets to backyard gardeners selling extra produce. This app will allow me to connect with other gardeners and fresh, local food lovers to share/sell/trade from our gardens. 14 | 15 | Features: 16 | 17 | * Fresh food directory (maybe with a map) 18 | * User profile and ability to list your local food product 19 | * Local listings of food product made available by other users 20 | 21 | ### Target Audience 22 | 23 | Anyone that enjoys fresh, local food. People that would like to sell their homemade or homegrown food products. 24 | 25 | ### Integrations 26 | 27 | * Twitter 28 | * [Farmer's market directory](http://catalog.data.gov/dataset/farmers-markets-geographic-data) 29 | * Twitter - Allow user to post their listings on twitter 30 | * Mandrill for email 31 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/chavez_horacio.md: -------------------------------------------------------------------------------- 1 | ### biker 2 | 3 | #### Pitch 4 | Let's build a stronger bike/tech community. 5 | 6 | #### Description 7 | **biker** 8 | 9 | 1. It lets you create and share bike routes. 10 | 2. You can also create races and tournaments based on those routes. 11 | 3. You can charge/pay to participate on a race/tour. 12 | 4. A tour can only be created after a user "creates it" and it receive certain support, which means _n_ participants and/or _n_ tweets. 13 | 5. You can track your performance and compare it with others. 14 | 6. Google API is going to be integrated. 15 | 7. You can receive notifications about the race thru SMS or email (on your choice) 16 | 8. As a user, you can send an email with a picture of the race, and it will be in your profile. 17 | 9. NOAA Dataset to predict the weather for your future (months in advance) race/tours. 18 | 19 | #### Target Audience 20 | bike riders. 21 | Tech enthusiast. 22 | 23 | #### Integrations 24 | National Oceanic and Atmospheric Administration Dataset (to predict the weather in advance for any race) 25 | Google OAuth - almost everyone have a Gmail (https://developers.google.com/accounts/docs/OAuth2) 26 | Google Maps API 27 | Twilio 28 | Twitter 29 | -------------------------------------------------------------------------------- /1412/challenges/chisel.markdown: -------------------------------------------------------------------------------- 1 | ## Chisel 2 | 3 | * Challenge: https://github.com/turingschool/challenges/blob/master/chisel.markdown 4 | * Due: 1/12/14 5 | 6 | ### Submissions 7 | 8 | * Andrew Overby: 9 | * Austin Wood: https://github.com/indiesquidge/chisel-redo 10 | * Charles Valentino Espinoza: https://github.com/xvalentino/chisel 11 | * DJ Greenfield: https://github.com/AllPurposeName/Chisel 12 | * David E Maurer:https://github.com/abstractrandom/challenges 13 | * Edward McCarthy: https://github.com/mcshakes/markdown_parser 14 | * Fred Block: https://github.com/blocknroll/chisel_02 15 | * Jack Yeh: 16 | * Jeffrey Gu: https://github.com/indiesquidge/chisel-redo 17 | * Juan Manuel Navarro: https://github.com/gomav/Chisel_Parser.git 18 | * Kyle Henson: https://github.com/kylehenson/chisel.git 19 | * Kyra Weber:https://github.com/kyraweber/new_chisel 20 | * Lori Culberson:https://github.com/loriculberson/chisel 21 | * Markus Olsen: https://github.com/neslom/chisel 22 | * Miriam Moser: https://github.com/mirjoy/chisel_parser_number_two 23 | * Paul Grever: https://github.com/paulgrever/chisel 24 | * Stanley Siudzinski: 25 | * Teresa Finn: https://github.com/teresafinn/chisel 26 | * Trey Tomlinson: https://github.com/treyyyy/chisel.markdown 27 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/mastery_project/2nd_bookshelf.rb: -------------------------------------------------------------------------------- 1 | { 2 | :developers => ["John Maddux"], 3 | :project_name => "2nd Bookshelf", 4 | :project_description => "I love books; I want more people to have access to more books, so I am building out a Netflix for books. I started 2ndbookshelf.com as a first iteration of this last weekend and I want to continue it. Many of the problems associated with running a service like this are non-technical but have technical solutions like inventory management, limiting the service area, and calculating the profitability of books. I have a list of features I would eventually like to implement but would certainly only get through the first few in the next 10 days: 1. Payment with Stripe or Paypal. 2. Allow admins to create books from within the app and allow rating and longer descriptions. 3. Admin tools to see which books are in demand and see what percantage of the time they are available (visualized with D3). 4. Service area to limit the area where people can signup for an account so we don't ship books to Alaska, etc. 5. Lots more stuff I wouldn't have time to get to I am sure.", 5 | :backend_technologies => ['PayPal, Stripe'], 6 | :frontend_technologies => ['D3'], 7 | :repo => 'http://github.com/jemaddux/2ndbookcase' 8 | } 9 | -------------------------------------------------------------------------------- /archive/1406/09_mastery/01 - micro check-ins.markdown: -------------------------------------------------------------------------------- 1 | Job Basket: 2 | 3 | ### Finder 4 | 5 | * Finding job listings 6 | * Filter them by location, stack 7 | * Listings directly created, maybe auto-import 8 | * List companies with more details about the company 9 | * Track the application process 10 | * Resources with example resume, coding challenges, etc 11 | * Track alumni current jobs 12 | 13 | ### MentorSHIP 14 | 15 | * It's hard to start connecting with mentors 16 | * A lot of people pair with mentors from other posses 17 | * Find the right mentor for the problem you're having 18 | * Ease the ramp-up for new students 19 | 20 | ### Warm It Up 21 | 22 | * Increase warmup engagement 23 | * Submitting code indicates engagement 24 | * Gamify the warmup 25 | * Daily problem has an answer 26 | * Get a score based on completion & correctness 27 | 28 | ### All the Feels 29 | 30 | * As a student we have this very emotional experience over the seven months 31 | * Wouldn't it be cool to track more info on a daily basis 32 | * Bring back old entries, etc 33 | * Login with Github, use the teams 34 | * Tuesday 35 | * Web-based writing 36 | * Emoji dropdown 37 | * Email reminder with link 38 | * Browse old entries 39 | * Login with Github 40 | * Ask for email/phone 41 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/suss_kyle.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Suss", 3 | :first_name => "Kyle", 4 | :project_name => "Progressive Dealer", 5 | :project_description => "Automotive website providers are slow, outdated, & unreliable in their practices. In the long term, this project is an attempt at building a fully functioning automotive dealership website. For this short project, the app will complete the first phase of the platform -- an automated inventory importer tool that interfaces with Rackspace Cloud Files & Sendgrid. Rackspace Cloud Files will be used to store inventory files as it is one of the few cloud storage providers that can receive data via FTP. While there are better technologies available, the automotive industry data providers only export data to third parties via FTP. Sendgrid will be utilized to inform the necessary parties about the status of the import and whether or not action must be taken in order to retrieve updated data. At it's completion, the project will serve as the backend for a tool that can be used for sales, reporting, and analysis of an automotive dealership.", 6 | :technologies => ['compass'], 7 | :integrations => ['sendgrid'], 8 | :repo => 'https://github.com/kylesuss/progressive-dealer.git', 9 | :heroku_account => 'susskyle@gmail.com' 10 | } -------------------------------------------------------------------------------- /1409/07_self_directed_project/lane_kate.md: -------------------------------------------------------------------------------- 1 | ### Just Talkin’ About Congress 2 | 3 | ### Pitch 4 | This app visualizes/filters the words used in the Congressional Record, giving you an at-a-glance view of which issues lawmakers address on a daily, weekly, monthly and yearly basis. 5 | 6 | ### Problem 7 | Keeping up with Congress — what they’re doing now and what they’ve already done — is a time-consuming task. There needs to be a way to search by keyword or phrase to find what’s been said about specific issues. 8 | 9 | ### Solution 10 | 11 | The JTAC app lets you filter words spoken by lawmakers on the House and Senate floor, allowing you to search for keywords and phrases of your choosing. Users are encouraged to share their findings on social media, to generate discussion of issues. 12 | 13 | ### Target Audience 14 | Concerned citizens, registered voters, internet trolls, academics. 15 | 16 | ### Integrations 17 | * Twitter makes sense as the OAuth provider here. Users can log in with their Twitter account and then share their search results. (Example tweet: Did you know Mark Quigley (IL-D) spoke to Congress about pizza in 2009?) 18 | * I'll use Sunlight Foundation’s Capitol Words API, possibly also their Congress API to pull in relevant info about legislators 19 | * I might also use Google maps or another mapping integration 20 | -------------------------------------------------------------------------------- /1502/challenges/chisel.markdown: -------------------------------------------------------------------------------- 1 | ## Submissions 2 | 3 | * Andrew Carmer: https://github.com/Carmer/Chisel 4 | * Chelsea Worrel: (https://github.com/chelseaworrel/Chisel.git) 5 | * David Daniel: (replace with your repo url here) 6 | * Dmitry Vizersky: (replace with your repo url here) 7 | * Eric Dowty: (https://github.com/end3rs-army/chisel_redux) 8 | * Eugene Khanutin: (replace with your repo url here) 9 | * Jack Yeh: (replace with your repo url here) 10 | * Jamie Kawahara: https://github.com/androidgrl/week3.git 11 | * Kenny Chen: (https://github.com/boomkenster/Chisel) 12 | * Kristina Brown: (https://github.com/kristinabrown/chisel) 13 | * Kyle Henson: (replace with your repo url here) 14 | * Michael Merrill: (replace with your repo url here) 15 | * Michelle Golle: (https://github.com/MichelleGolle/Chisel) 16 | * Mihir Parikh: (https://github.com/mihir787/chisel.git) 17 | * Minnie Lee: (replace with your repo url here) 18 | * Patrick Medaugh: (replace with your repo url here) 19 | * Rob Cornell: (https://github.com/kurohyou108/chisel/blob/master/README.md) 20 | * Tess Griffin: (https://github.com/tessgriffin/chisel) 21 | * Thomas Leskin: (replace with your repo url here) 22 | * Tony DiNitto: (replace with your repo url here) 23 | * Tracy Caruso: (replace with your repo url here) 24 | * Tyler Graham: (replace with your repo url here) 25 | -------------------------------------------------------------------------------- /archive/gschool-1/reading/cycle_5.markdown: -------------------------------------------------------------------------------- 1 | ### Texts 2 | 3 | For this cycle, please select a text from our [Ruby Texts](http://tutorials.jumpstartlab.com/reading/suggestions/ruby_texts.html) suggestions and add the title below. 4 | 5 | #### Example 6 | 7 | * Jeff Casimir - Design Patterns in Ruby 8 | 9 | ### Selections 10 | 11 | * Antony Siegert - Practical Object-Oriented Design with Ruby 12 | * Ben Horne - Practical Object-Oriented Design with Ruby 13 | * Ben Lewis - Design Patterns in Ruby 14 | * Billy Griffin - Practical Object-Oriented Design 15 | * Bree Thomas - Russ Olsen’s Eloquent Ruby 16 | * Brian Winterling - POODR 17 | * Bryana Knight - 18 | * Darryl Pequeen - 19 | * George Hudson - POODR 20 | * Jonah Moses - 21 | * Katrina Engelsted - Russ Olsen’s Eloquent Ruby 22 | * Kevin Powell - 23 | * Lauren Spath Luhring - 24 | * Louisa Barrett - Sandi Metz' POODR 25 | * Luke Martinez - Sandi Metz’ Practical Object-Oriented Design with Ruby 26 | * Magan Adam - Eloquent Ruby 27 | * Nathaniel Watts - Design Patterns in Ruby 28 | * Nikhil Taneja - 29 | * Persa Zula - POODR 30 | * Quentin Tai - Refactoring: Ruby Edition 31 | * Rolen Le - Design Patterns in Ruby. To The Moon! 32 | * Romeeka Gayhart - 33 | * Simon Taranto - Design Patterns in Ruby 34 | * Tyler Long - Practical Object-Oriented Design in Ruby 35 | * Will Mitchell - 36 | -------------------------------------------------------------------------------- /1409/04_clone_wars/checkins/zach-travis-chase: -------------------------------------------------------------------------------- 1 | Checkin with: Josh Cheek 2 | Zach Travis Chase 3 | 4 | Delete the yaml stuff 5 | 6 | 1 at a time: 7 | Pick a thing (probably /dine-in) 8 | step 9 | take the menu and start daynamically filling in the data 10 | based on a hash that you set in your controller 11 | step 12 | make an admin endpoint 13 | ignore authentication 14 | render your form 15 | step 16 | that form posts to another admin endpoint 17 | step 18 | once the db stuff is in place 19 | go to the menu view (the one users see) replace that hash with data from the db 20 | step 21 | once the db stuff is in place 22 | go to the admin endpoint and save it into the db 23 | step 24 | once authentication is available 25 | stick it on the admin endpoints 26 | Authentication 27 | Figure out how to use basic HTTP auth (or whatever is simple and easy) 28 | Put a method into your app that you can call to auth a request 29 | Database 30 | Figure out what the fuck "database" even means for your app 31 | do it locally 32 | against postgres 33 | Figure out your heroku database credentials 34 | $ heroku run bash 35 | $ echo $DATABASE_URL 36 | might need to figure out how to parse the url 37 | or maybe Sequel can straight take the url 38 | 39 | -------------------------------------------------------------------------------- /1409/07_self_directed_project/routhier_zach.md: -------------------------------------------------------------------------------- 1 | ### Mousiki 2 | 3 | ### Pitch 4 | 5 | A website that automatically populates a concert tracker from your Spotify's most listened to artists and lets you know when they are playing in your area. 6 | 7 | ### Problem 8 | 9 | Most of today's solutions for finding concerts involve going to Ticketmaster, or Songkick, or the artists tour dates on their webpage and manually finding them. 10 | 11 | We are all very busy people and sometimes we just don't have the time to go find concerts for a band we are interested in. Sometimes we just forgot and the concert comes and tomorrows too late. 12 | 13 | ### Solution 14 | 15 | Mousiki automatically populates the the concert finder with your Spotify music that you already listen to. It will populate the concerts based on how soon the artist is coming to your city and then will also show you which music you listen to the most and put those in your favorites. 16 | 17 | This way you don't have to keep track of any artists, as you listen to more and different music and artists the app will automatically update and show you when these artists are coming to play at a city near you 18 | 19 | ### Target Audience 20 | 21 | Everyone who listens to music and currently does, or does not attend concerts. 22 | 23 | ### Integrations 24 | 25 | * SongKick API 26 | * Spotify API 27 | -------------------------------------------------------------------------------- /archive/1406/08_feed_engine/tunefish.markdown: -------------------------------------------------------------------------------- 1 | 2 | ## Notes 3 | 4 | * For Today: logging in with OAuth, pull information from APIs, starting to build a feed 5 | * Been working on OAuth, Ember app, built a client for getting data from the YouTube API, getting only music, getting the videos, get the subscriptions from youtube, track subscriptions in the database 6 | * Tuesday: wireframes implemented into html/views, register for the site, link twitter, last.fm, youtube, soundcloud, feed displays youtube embedded videos from the channels that I subscribe to on youtube => Customer Ready 7 | 8 | ## Scoring 9 | 10 | Skipped scoring as the product is dramatically behind expectations. 11 | 12 | ## Final Evaluation 13 | 14 | ### Notes 15 | 16 | * Experience 17 | * Lots of cool tech bits 18 | * Good source data 19 | * Good design effort 20 | * Needs some UX thinking 21 | * Subscription feature is neat from proof-of-concept level 22 | 23 | ### Scores 24 | 25 | * A: API - 3, good with a few network-dependent tests 26 | * B: Workers - 3, good, but would like to see them use the API 27 | * C: TDD - 2, some failures, would like to see coverage of network/service problems 28 | * D: Technical - 3, tool could be better used, processes ok 29 | 30 | * A: Deployment - 4, glad docker plan worked out 31 | * B: Features - 3, subscriptions are a bit half-baked, but ok 32 | * C: Interface - 3 33 | * D: Concept - 3 34 | -------------------------------------------------------------------------------- /archive/1406/08_feed_engine/snowcial.markdown: -------------------------------------------------------------------------------- 1 | 2 | ## Notes 3 | 4 | * To be done today: CRUD of groups, trips users 5 | * Status: most CRUD available on the API side, not yet on the Ember side. Can list groups, show one. 6 | * Tuesday: create a group, invite people to the group, create a trip, fetch public tweets that occur during a trip, display all group member tweets in a single timeline in the trip view -- CUSTOMER READY 7 | * Write at least one "epic" test 8 | 9 | ## Scoring 10 | 11 | ### Feature Delivery 12 | 13 | * Completion: 2 14 | * Organization: 1 15 | * Progress: 2 16 | 17 | #### Technical Quality 18 | 19 | * Test-Driven Development: 2.5 20 | * Code Quality: ? 21 | * User Experience: 1 22 | 23 | === 24 | 25 | ## Final Evaluation 26 | 27 | ### Notes 28 | 29 | * Project Tracker - Not a lot of stories but most are done 30 | * Functionality 31 | * Login with twitter 32 | * Create trip 33 | * Invite people 34 | * They can accept 35 | * Current weather 36 | * Some EpicMix integration 37 | * Technical 38 | * APIs are wrapped fine, API is insecure but does some things, wrapper gem done well 39 | * 18 tests, api is ok tested, rest is kind of ... ? 40 | 41 | ### Scores 42 | 43 | * A: API - 3 44 | * B: Workers - 2, one email in request, need to use API 45 | * C: TDD - 1 46 | * D: Technical - 1.895 47 | 48 | * A: Deployment - 4 49 | * B: Features - 2 50 | * C: Interface - 3 51 | * D: Concept - 2 52 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/feed_engine.rb: -------------------------------------------------------------------------------- 1 | # Add your git repo URL and 2 | # one or more collaborator accounts for push access 3 | 4 | def project 5 | { 6 | :photoline => {:repo => 'https://github.com/pnblackwell/feed_engine.git', 7 | :collaborators => ['lauramsteadman@gmail.com','jen7maples@gmail.com', 'pnblackwell@gmail.com', 'dannygarcia.me@gmail.com']}, 8 | :softline => {:repo => 'https://github.com/blairanderson/alpha-feed-engine', 9 | :collaborators => ['blair81@gmail.com']}, 10 | :chatline => {:repo => 'https://github.com/Diasporism/feed_engine.git', 11 | :collaborators => ['lsears322@gmail.com', 'chelseakomlo@gmail.com', 'danmee10@gmail.com']}, 12 | :traveline => {:repo => 'https://github.com/raphweiner/feed_engine', 13 | :collaborators => ['raphael.weiner@gmail.com', 'e.b.drummond@gmail.com']}, 14 | :tuneline => {:repo => 'https://github.com/aimzatron/feed_engine', 15 | :collaborators => ['aimee@geekycheeks.com', 'chrisknight.mail@gmail.com', 'rogerssh@tcd.oe', 'joshua.mejia@gmail.com']} 16 | :runline => {:repo => 'git@github.com:bradpsheehan/feed_engine.git', 17 | :collaborators => ['bradpsheehan@gmail.com', 'lalalainexd@gmail.com.com', 'jemaddux@gmail.com', 'kareem@getuserwise.com']} 18 | } 19 | end 20 | 21 | def config 22 | {:abbreviation => 'feed'} 23 | end 24 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/weiner_raphael.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Weiner", 3 | :first_name => "Raphael", 4 | :project_name => "Elefeely", 5 | :project_description => "How did you feel last week? How about last month? Elefeely will help you remember. We'll text you once a day, and store your feelings in our elephants' ginormous memories. The project is comprised of four parts: two services, one gem, and one client. 1. Elefeely-api (central api, where our elephants reside and store your feelings), 2. Elefeely-twilio-interface (service that coordinates sending feeling requests and posting new ones to the Elefeely-api), 3. Elefeely gem (retrieve feelings and post new ones, used in the Elefeely-twilio-interface and available to the world), and 4. Javascript front-end (interfaces with the Elefeely-api to present your feelings, and the collective's).", 6 | :technologies => ['riak', 'javascript front-end'], 7 | :integrations => ['twilio'], 8 | :repo => ['http://github.com/raphweiner/elefeely-api', 9 | 'http://github.com/raphweiner/elefeely-twilio-interface', 10 | 'http://github.com/raphweiner/elefeely', 11 | 'http://github.com/raphweiner/elefeely-ui'], 12 | :heroku_account => 'raphael.weiner@gmail.com', 13 | :needs_heroku_setup => true, 14 | :needs_workers => true, 15 | :needs_redis_to_go => true, 16 | :other_needs => ["2 dynos: 1 for scheduler, 1 for worker"] 17 | } 18 | -------------------------------------------------------------------------------- /archive/1406/06_the_pivot/the_pivot.markdown: -------------------------------------------------------------------------------- 1 | Keevahh: 2 | * Registering and posting loans works ok 3 | * Some browsing works 4 | 5 | * Completion: 3 6 | * Organization: 3 7 | * Progress: 3 8 | Technical: 9 | * Lots of pending tests 10 | * 61% coverage 11 | * TDD: 2 12 | * Code Quality: 3? 13 | * UX: 2 14 | 15 | EmployMe 16 | * Decent user registration and posting of jobs 17 | * Product 18 | * Completion: 3 19 | * Organization: 3 20 | * Progress: 3 21 | * Technical 22 | * Notes 23 | * `rake spec` suite doesn't run 24 | * some tests fail 25 | * haven't removed irrelevant features/specs 26 | * not really using tests as a suite 27 | * Scores 28 | * TDD: 1 29 | * Code Quality: 3 30 | * UX: 2 31 | 32 | Airlift 33 | * Overall good work leading up to this point 34 | * Some decent work in UX 35 | * Product 36 | * Completion: 3 37 | * Organization: 3 38 | * Progress: 3 39 | * Technical 40 | * Notes 41 | * Love that the tests are all green 42 | * Great scores from Code Climate 43 | * Scores: 44 | * TDD: 4 45 | * Code Quality: 46 | * UX: 2 47 | 48 | TravelHome 49 | * Great work on the UX 50 | * Signup works well 51 | * Product 52 | * Completion: 3 53 | * Organization: 3 54 | * Progress: 3 55 | * Technical 56 | * TDD: 3 57 | * Code Quality: 3? Setup code climate 58 | * UX: 4 59 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/individual_projects/sheehan_bradley.rb: -------------------------------------------------------------------------------- 1 | { 2 | :last_name => "Sheehan", 3 | :first_name => "Bradley", 4 | :project_name => "Artistic Streets", 5 | :project_description => "In our fast-paced world where digital distrations keep our eyes on the screen, we often overlook the things which make their city or town unique/beautiful. That is, the things that give a location a sense of place, like public art. Using Boston as a starting point, my application will leverage technology (such as google maps, twitter, and instagram) and the plethora of public art infused into the city to get people to lift their heads to the world that surrounds them. The two core features of this app are 1) Help people discover public art. The user will be able to enter a zipcode which will then show a filtered gallery and google map with pins of public art in that zipcode. 2) Help people contribute to the documentary of public art. The user will be able to contribute to this documentary of public art by submitting the art-piece via our app directly, or via twitter & instagram using a specific hash tag", 6 | :technologies => ['Internationalization'], 7 | :integrations => ['google maps', 'instagram'] 8 | :repo => 'http://github.com/username/repo_name', 9 | :heroku_account => 'bradpsheehan@gmail.com' 10 | :needs_heroku_setup => true, 11 | :needs_workers => true, 12 | :needs_redis_to_go => true, 13 | :other_needs => ["none"] 14 | } 15 | -------------------------------------------------------------------------------- /1409/04_clone_wars/checkins/tim-greg-konr: -------------------------------------------------------------------------------- 1 | Checkin with: Josh Cheek 2 | Timothy, Gregory, Konr 3 | 4 | high priority 5 | make "GET /menu" dynamic based on data from a controller. e.g. 6 | get '/menu' do 7 | @menu = [ 8 | {name: 'Shared Bites', 9 | items: [ 10 | { name: 'Greek Nachos'. 11 | price: '8', 12 | description: 'House made pita chips, hummus, gyro meat drizzled with red pepper aioli and raita sauce.' 13 | }, 14 | ]} 15 | ] 16 | end 17 | 18 | <% @menu.each do |category| %> 19 |

<%= category[:name] %>

20 | 24 | can get menu items out of the database into some sort of usable form 25 | admin form: 26 | endpoint for "GET /admin/menu" renders a form based on same dynamic data as "GET /menu" 27 | form submits to "POST /admin/menu" (make an endpoint -- it does nothing -- but is authenticated) 28 | renders a form with the data filled in 29 | once you can get data out: 30 | generate the menu at "GET /menu" via the database data instead of being hard-coded in the view 31 | generate the form at "GET /admin/menu" via the db data 32 | when form is submitted "POST /admin/menu" take the form data and save it into the database 33 | 34 | low priority 35 | to fix the links: 36 | change "http://whatever.com/something" into "/something" 37 | extensions 38 | -------------------------------------------------------------------------------- /archive/gschool-0/writing/index.markdown: -------------------------------------------------------------------------------- 1 | ## Class Blog Index 2 | 3 | Add the "live" URL for your class blog. 4 | 5 | * Jeff Casimir: http://jumpstartlab.com/news 6 | 7 | ### Student Submissions 8 | 9 | * Blair Anderson: http://blairbuilds.herokuapp.com 10 | * Paul Blackwell: http://paulblackwell.herokuapp.com/ 11 | * Phil Battos: http://phliptos.herokuapp.com/ 12 | * Erin Drummond: http://ebdrummond.com/ 13 | * James Denman: http://xacaxulu-blog.herokuapp.com/ 14 | * Jennifer Eliuk: http://eliuk-gschool-blog.herokuapp.com 15 | * Danny Garcia: http://dannygarcia.herokuapp.com/ 16 | * Kareem Grant: http://gthang.herokuapp.com/ 17 | * Christopher Knight: http://serknight.herokuapp.com/ 18 | * Chelsea Komlo: http://komlo.herokuapp.com 19 | * John Maddux: http://jmaddux-blog.herokuapp.com/ 20 | * Aimee Maher: http://gschool-blog.herokuapp.com 21 | * Josh Mejia: http://jmejia.herokuapp.com/ 22 | * Daniel Mee: http://danielmee.herokuapp.com 23 | * Ron Rateau: http://writersblock.herokuapp.com/ 24 | * Shane Rogers: http://shaneblog.herokuapp.com/ 25 | * Laura Steadman: http://refactoring-rainbows.herokuapp.com/ 26 | * Geoffrey Schorkopf: http://geoffsblog.herokuapp.com/ 27 | * Kyle Suss: http://kylesuss.com/ 28 | * Logan Sears: http://logan-gschool.herokuapp.com/ 29 | * Bradley Sheehan: http://bradsheehan.herokuapp.com 30 | * Elaine Tai: http://lalalainexd-blog.herokuapp.com/ 31 | * Jorge Tellez: http://novohispanoblog.herokuapp.com/ 32 | * Raphael Weiner: http://raphaelio.herokuapp.com/ 33 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/davis_corey.markdown: -------------------------------------------------------------------------------- 1 | ### Title 2 | Skate Ways (reserving the right to change) 3 | 4 | **SELECTED** 5 | 6 | #### Pitch 7 | 8 | Skate Ways uses data from http://data.opencolorado.org/dataset/city-and-county-of-denver-skate-parks to help you find the skate park closest to you and allows you to see who's FourSquare checked-in there in the last three hours. 9 | 10 | #### Description 11 | 12 | The app will allow users to find current skate spots, and add their own. In addition users can upload images of features and rank them and describe. Foursquare checkins as well so you can see if people you know are skating. There will be a trick challenge section as well were users can upload vines of tricks on a specific feature and then rank other users tricks. 13 | 14 | #### Target 15 | 16 | Anyone who skates, scoots, or trick bikes. Maybe some of those fruitbag roller bladers too, though I might try to find a way to descrimahate on them cause lame. If there is time I might try to build in something for Urban Snowboarders too, because they are more fun then the whole lot of wheelheads. AND there is NOTHING out there for them, mostly because it's illegal in most places, but meh. 17 | 18 | #### Integrations 19 | 20 | * [What OAuth provider makes sense for this audience?] 21 | Facebook most likely or foursquare if they have one 22 | 23 | * [What Data.gov data or API will you use?] 24 | http://data.opencolorado.org/dataset/city-and-county-of-denver-skate-parks 25 | 26 | 27 | * [Any other integrations?] -------------------------------------------------------------------------------- /archive/1406/08_feed_engine/successive_life.markdown: -------------------------------------------------------------------------------- 1 | 2 | ## Notes 3 | 4 | * Goal for today: landing page, basics of creating a goal/streak, get the VPS started 5 | * A few buttons and forms in place 6 | * Login with Twitter 7 | 8 | ## Scoring 9 | 10 | ### Feature Delivery 11 | 12 | * Completion: 2 13 | * Organization: 3 14 | * Progress: ? 15 | 16 | #### Technical Quality 17 | 18 | * Test-Driven Development: 1 19 | * Code Quality: ? 20 | * User Experience: 1.5 21 | 22 | ## Final Evaluation 23 | 24 | ### Notes 25 | 26 | * Project Tracker 27 | * Not used 28 | * Product Demo 29 | * Can't signup for github on the first try 30 | * Goodreads signup but can't set goals 31 | * GitHub integration works eventually 32 | * FitBit integration pulls data 33 | * Text message at 5PM if you haven't hit the goals for the day 34 | * Not a lot of functionality, but could be a good proof of concept 35 | * Code Dive 36 | * 29 tests, 91% coverage 37 | * wrapper gem is nice, API is small but functional 38 | * one worker implemented but has direct db access 39 | 40 | ### Scores 41 | 42 | * A: API - 2, need to create data, use it for workers 43 | * B: Workers - 2, github worker ok, need to use API and worker-ize other responsibilities 44 | * C: TDD - 2, need more depth to the test suit 45 | * D: Technical - 1, not used 46 | 47 | * A: Deployment - 2*, last minute problems 48 | * B: Features - 2, lots of proofs of concept 49 | * C: Interface - 2, some good parts 50 | * D: Concept - 1.5, could come together with a few more weeks work 51 | -------------------------------------------------------------------------------- /archive/gschool-0/reading/eloquent_ruby/rg2/group_4_notes.markdown: -------------------------------------------------------------------------------- 1 | ## RG2 Notes for Eloquent Ruby 2 | 3 | ### Short Methods (CH10) & Operators (CH11) & Equality (CH12) 4 | 5 | #### Key Ideas - Use short methods to maintain simplicty. 6 | 7 | #### The Highlight - Beware transitive property assumptions. If a = b and b = c, then a is not always = to c. 8 | 9 | #### The Lowlight - The === was confusing as to when we would ever use this. 10 | 11 | ### Singletons (CH13) & Class Instance Variables (CH14) 12 | 13 | #### Key Ideas - Class methods are singleton methods because classes are instances of objects. 14 | 15 | #### The Highlight - Don't use class method variables or they will cause problems. 16 | 17 | #### The Lowlight - Singleton methods are still confusing. We don't know when to use them. 18 | 19 | ### Modules as Namespaces (CH15) & Mixins (CH16) 20 | 21 | #### Key Ideas - Namespaces are used to remove naming conflicts between your classes and other classes. 22 | 23 | #### The Highlight - Mixins are used to shared code between classes. 24 | 25 | #### The Lowlight - Why do require paths not prevent namespace conflicts? 26 | 27 | ### Blocks (CH17) & Execute Around (CH18) & Execute Later (CH19) 28 | 29 | #### Key Ideas - Chapter 18 talked about naming methods carefully. 30 | 31 | #### The Highlight - Execute Around - coping with times when code needs to come before or after some code or both 32 | 33 | #### The Lowlight - Why include Ennumerable if you already get all the methods on a collection? 34 | -------------------------------------------------------------------------------- /1410/05_traffic_spy/traffic_spy.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | Lydia, Laura, & Kit: 3 | repository: https://github.com/kpearson/traffic_spy 4 | setup_notes: "" 5 | instructor_evaluation: 6 | notes: "Good test coverage and use of TDD. Missing functionality, but well-written code." 7 | rubric: 8 | Functional Expectations: 2 9 | Test-Driven Development: 3.5 10 | Encapsulation / Components: 3.5 11 | Fundamental Ruby & Style: 3 12 | Sinatra / Web and Business Logic: 3.5 13 | View Layer: 3 14 | submissions: 15 | Rich, Jeff, & Brandon: 16 | repository: https://github.com/Jwan622/traffic_spy 17 | setup_notes: 18 | instructor_evaluation: 19 | notes: "All base functionality. Application works, but some messy mixing of logic." 20 | rubric: 21 | Functional Expectations: 3 22 | Test-Driven Development: 2 23 | Encapsulation / Components: 3 24 | Fundamental Ruby & Style: 3 25 | Sinatra / Web and Business Logic: 3 26 | View Layer: 3 27 | submissions: 28 | Bhargavi, Alex, & Mike: 29 | repository: https://github.com/Jwan622/traffic_spy 30 | setup_notes: 31 | instructor_evaluation: 32 | notes: "All base functionality plus JSON and basic HTTP auth." 33 | rubric: 34 | Functional Expectations: 4 35 | Test-Driven Development: 2 36 | Encapsulation / Components: 3.5 37 | Fundamental Ruby & Style: 3 38 | Sinatra / Web and Business Logic: 4 39 | View Layer: 3.5 40 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/will_faurot.md: -------------------------------------------------------------------------------- 1 | ### [Project Title] 2 | 3 | Open State Colorado (subject to change) **SELECTED** 4 | 5 | #### Pitch 6 | 7 | Based on location data and issues, present meaningful data retrieved from the 8 | open-states API. 9 | 10 | #### Description 11 | 12 | A user will be able to input some location information, specify issues that they 13 | are interested in, and recieve information about state-level government issues. 14 | The two major features as I see them: users can be notified about bills in 15 | progress that deal with issues they have selected, giving them very clear 16 | options for who to contact should they want to get involved (sponsor_id as part 17 | of a reqeust for a bill is an option here). Users could also see voting 18 | records from local representatives based on specified issues. 19 | 20 | #### Target Audience 21 | 22 | People interested in government issues at a state level who don't want to have 23 | to dig to find bills/representatives relevant to their interests. 24 | 25 | #### Integrations 26 | 27 | * [What OAuth provider makes sense for this audience?] 28 | Trying to cast the widest net might be my best option, so google/fb/twitter. 29 | 30 | * [What Data.gov data or API will you use?] 31 | This is where this idea shines I think, the Open States API from sunlight labs 32 | (thanks jeff) is robust and has good documentation 33 | 34 | * [Any other integrations?] 35 | Possibly some integration that makes it stupidly easy to contact a representative, 36 | such as being sms'd a phone number. 37 | -------------------------------------------------------------------------------- /archive/1406/08_feed_engine/footprints.markdown: -------------------------------------------------------------------------------- 1 | 2 | ## Notes 3 | 4 | * Goal for today: wireframing, instagram omniauth 5 | * Tuesday: 6 | * level 0: customer-ready application, register/signup, create a trip, see my photos in the trip 7 | * level 1: add users to trip by username without consent, their photos appear in the trip 8 | * level 2: invite users to a trip, they consent, their photos are added 9 | * level 3: a trip has an aggregated map rolling up all known events/photos 10 | * Start ripping the Instagram integration out to background workers 11 | 12 | ## Scoring 13 | 14 | ### Feature Delivery 15 | 16 | * Completion: 3 17 | * Organization: 3 18 | * Progress: 3 19 | 20 | #### Technical Quality 21 | 22 | * Test-Driven Development: 2 23 | * Code Quality: ? 24 | * User Experience: 2.5 25 | 26 | ## Final Evaluation 27 | 28 | ### Notes 29 | 30 | * Last days: user experience, adding a map, removing duplicate records, added caching, wrapper gem for API 31 | * Project Management: good usage, nothing major left undone 32 | * Product Tour: 33 | * Running on localhost 34 | * Having trouble loading data initially 35 | * Need more data to show off the functionality 36 | * The Code: 37 | * overall good 38 | * testing is solid on happy path, need more unhappy path 39 | * API is kind of proof of concept but has a gem 40 | 41 | ### Scores 42 | 43 | * A: API - 3 44 | * B: Workers - 2 need to use your own API 45 | * C: TDD - 2 need more unhappy path tests 46 | * D: Technical - 4 47 | 48 | * A: Deployment - 1* 49 | * B: Features - 3 50 | * C: Interface - 3 51 | * D: Concept - 3 52 | -------------------------------------------------------------------------------- /blogging/2014-10-03.markdown: -------------------------------------------------------------------------------- 1 | Please add the link to your technical blog post below: 2 | 3 | * Aaron Paul Wortham: 4 | * Adam Smith: this is provisional: http://limitless-basin-1982.herokuapp.com/ 5 | * Alan Smith: 6 | * Alex Jensen: http://rubywithalex.herokuapp.com/ 7 | * Allison Larson: 8 | * Andrew Watkins: 9 | * Andy Mention: 10 | * Cara Dennis: 11 | * Chad Brading: 12 | * Chandra Carney: 13 | * Chase van Hekken: https://medium.com/@ChasevH/the-ruby-send-method-afe882a8191c 14 | * Christopher Bynum: 15 | * Corey Davis: 16 | * Danny Glunz: http://www.danielglunz.com/github/gitting-started/ 17 | * David Bayendor: 18 | * Emily Davis: 19 | * Eric Fransen: 20 | * Glen Egbert: 21 | * Gregory Narajka: https://greg-turing.ghost.io/how-to-print-tables-to-the-command-line-a-pastiche-of-real-korean-high-school-student-essays/ 22 | * Gustavo Villagrana: 23 | * Herbert Joseph: 24 | * Hilary Denton: 25 | * Horacio Chavez: 26 | * Ian Andersen: http://www.mindfulprogramming.com/creating-an-admin-controller-in-rails/ 27 | * Jessica Goulding: 28 | * Jim Sutton: 29 | * Jonmichael Chambers: 30 | * Kalah Cheek: 31 | * Kate Lane: http://t.co/nMzendlnZK 32 | * Kavita Sachdeva: 33 | * Konr Josef Laron: 34 | * Luke Aiken: 35 | * Marc Garreau: 36 | * Robert Gu: 37 | * Rolando Navarrete: http://chaosruby.com 38 | * Sam Kuhlmann: 39 | * Sara Simon: 40 | * Tan Doan: 41 | * Tim Proctor: 42 | * Timothy Mee: 43 | * Travis Yoder: 44 | * Victoria Harrod: http://viki-at-turing.herokuapp.com/2014/10/03/first-pair-project-observations.html 45 | * Will Faurot: 46 | * Zachary Routhier: https://medium.com/@z_Routh/turing-event_reporter-89683517faac 47 | -------------------------------------------------------------------------------- /1409/04_clone_wars/checkins/adam-chandra-viki: -------------------------------------------------------------------------------- 1 | Checkin with: Josh Cheek 2 | Adam, Chandra, Viki 3 | 4 | no db 5 | do have admin 6 | do have auth 7 | 8 | high priority 9 | database 10 | play with Sequel until you can connect to your prod db 11 | ``` 12 | $ heroku run bash 13 | $ echo $DATABASE_URL 14 | ``` 15 | connect your app to your prod db 16 | create your schema in your prod db 17 | stick the location data into your prod db 18 | go help everyone doing the other shit 19 | data presented to users is dynamic 20 | edit the .erb file to generate the view from some type of data 21 | (I would start with an array of hashes) 22 | ability to edit the data 23 | a form to fill in 24 | make an endpoint: GET /admin/locations 25 | it renders a form with appropriate fields for a location 26 | ocne the db is in place, fill in the form data with the locations from the db 27 | submitting the form does shit 28 | another endpoint: POST /admin/locations 29 | once db is in place, it saves the form data into the db 30 | 31 | 32 | low priority 33 | Contact us 34 | make a local db 35 | 36 | ---- 37 | 38 | class YamlDb 39 | def load 40 | YamlStore.load[:data][:form] 41 | end 42 | end 43 | 44 | class PostgresDb 45 | def load 46 | DatabaseStore.execute('select * from thing where value = whatever').to_a 47 | end 48 | end 49 | 50 | get '/' do 51 | @locations = [ 52 | {name: 'Denver, CO', 53 | hours1: 'Mon - Fri 7 am - 6 pm ', 54 | ... 55 | Sat - Sun 8 am - 6 pm 56 | 57 | LoDo 58 | 1617 Wazee St 59 | Denver, CO 80202 60 | 303-534-7900} 61 | ] 62 | end 63 | 64 | 65 | 66 | 67 | 68 | -------------------------------------------------------------------------------- /1410/06_mini_project/06_mini_project.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | Rich Shea: 3 | repository: https://github.com/... 4 | setup_notes: "" 5 | Laura Whalin: 6 | repository: https://github.com/laurawhalin/idea_box_rails 7 | setup_notes: "" 8 | Jeff Wan: 9 | repository: https://github.com/... 10 | setup_notes: "" 11 | Bryce Holcomb: 12 | repository: https://github.com/... 13 | setup_notes: "" 14 | Nathan Owsiany: 15 | repository: https://github.com/ndwhtlssthr/idea_box_rails.git 16 | setup_notes: "" 17 | Emily Berkeley: 18 | repository: https://github.com/EmilyMB/idea_box_rails 19 | setup_notes: "" 20 | Alexandra Robinson: 21 | repository: https://github.com/... 22 | setup_notes: "" 23 | Michael Dao: 24 | repository: https://github.com/mikedao/new_idea_box 25 | setup_notes: It works. Mostly. Had some problems with authorization and stubbing tests. 26 | Orion Osborn: 27 | repository: https://github.com/... 28 | setup_notes: "" 29 | Bhargavi Satpathy: 30 | repository: https://github.com/bhargavisatpathy/secured_ideabox 31 | setup_notes: "" 32 | Krista A Nelson: 33 | repository: https://github.com/... 34 | setup_notes: "" 35 | Brandon Mrsny: 36 | repository: https://github.com/... 37 | setup_notes: "" 38 | Scott Crawford: 39 | repository: https://github.com/... 40 | setup_notes: "" 41 | Kit Pearson: 42 | repository: https://github.com/... 43 | setup_notes: "" 44 | Chris Luhring: 45 | repository: https://github.com/cluhring/ideabox_rails 46 | setup_notes: "" 47 | Lydia Shafer: 48 | repository: https://github.com/Lydias303/authentication-idea-box 49 | setup_notes: "" 50 | -------------------------------------------------------------------------------- /scripts/provision_heroku_servers.rb: -------------------------------------------------------------------------------- 1 | require './1407/06_the_pivot/submissions' 2 | 3 | class Provisioner 4 | def setup 5 | Dir.mkdir(temp_dir) 6 | Dir.chdir(temp_dir) 7 | end 8 | 9 | def temp_dir 10 | "#{config[:abbreviation]}_temp" 11 | end 12 | 13 | def clone_repository(repo, name) 14 | `git clone #{repo} #{name}` 15 | end 16 | 17 | def create_app(name) 18 | `heroku create #{config[:abbreviation]}-#{name}` 19 | end 20 | 21 | def setup_database 22 | db_message = `heroku addons:add heroku-postgresql:basic` 23 | db_name = db_message.scan(/Attached as (\S*)$/).first.first 24 | `heroku pg:promote #{db_name}` 25 | end 26 | 27 | def deploy 28 | `git push heroku master` 29 | `heroku run rake db:migrate` 30 | end 31 | 32 | def start_processes 33 | `heroku ps:scale web=1 worker=1` 34 | end 35 | 36 | def add_addons 37 | `heroku addons:add redistogo` 38 | `heroku addons:add newrelic:stark` 39 | end 40 | 41 | def add_collaborator(account) 42 | `heroku sharing:add #{account}` 43 | end 44 | 45 | def teardown 46 | `rm -rf #{temp_dir}` 47 | end 48 | 49 | def within_project_directory(name, &block) 50 | Dir.chdir(name.to_s) 51 | block.call 52 | Dir.chdir('..') 53 | end 54 | 55 | def run 56 | setup 57 | 58 | project.each do |identifier, details| 59 | clone_repository(details[:repo_url], details[:app_name]) 60 | 61 | within_project_directory(details[:app_name]) do 62 | create_app(details[:app_name]) 63 | setup_database 64 | add_addons 65 | deploy 66 | start_processes 67 | details[:collaborators].each{|account| add_collaborator(account)} 68 | end 69 | end 70 | 71 | teardown 72 | end 73 | end 74 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/warmup_exercises.markdown: -------------------------------------------------------------------------------- 1 | ## Warm-Up Exercise Repositories 2 | 3 | On Mondays through Thursdays we will post a warm-up exercise at 8:50. You will have until 9:15 to complete the exercise. 4 | 5 | Commit the code to your fork. 6 | 7 | We'll provide feedback in-line. 8 | 9 | If you have questions about the assignments, email Katrina at katrina@jumpstartlab.com. 10 | 11 | ## Repositories 12 | 13 | Each student should submit the URL to the github page for their warm-ups by submitting a pull request to this repo with the URL added below. Modify *only* the line with your name on it. 14 | 15 | ### Example 16 | 17 | * Katrina Owen: [https://github.com/JumpstartLab/warmup-exercises](https://github.com/JumpstartLab/warmup-exercises) 18 | 19 | ### Student Submissions 20 | 21 | * Blair Anderson: 22 | * Paul Blackwell: 23 | * Phil Battos: 24 | * Erin Drummond: https://github.com/ebdrummond/warmup-exercises.git 25 | * James Denman: 26 | * Jennifer Eliuk: https://github.com/7maples/warmup-exercises 27 | * Danny Garcia: https://github.com/danny-g/warmup-exercises 28 | * Kareem Grant: 29 | * Christopher Knight: https://github.com/SerKnight/warmup-exercises.git 30 | * Chelsea Komlo: 31 | * John Maddux: 32 | * Aimee Maher: 33 | * Josh Mejia: 34 | * Daniel Mee: 35 | * Ron Rateau: 36 | * Shane Rogers: 37 | * Laura Steadman: https://github.com/thesteady/warmup-exercises.git 38 | * Geoffrey Schorkopf: 39 | * Kyle Suss: https://github.com/kylesuss/warmup-exercises.git 40 | * Logan Sears: 41 | * Bradley Sheehan: https://github.com/bradpsheehan/warmup-exercises.git 42 | * Elaine Tai: https://github.com/lalalainexd/warmup-exercises.git 43 | * Jorge Tellez: https://github.com/novohispano/warmup-exercises.git 44 | * Raphael Weiner: https://github.com/raphweiner/warmup-exercises.git 45 | 46 | -------------------------------------------------------------------------------- /archive/1406/08_feed_engine/submissions.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | group1: 3 | app_name: "footprints" 4 | members: 5 | repo_url: 6 | production_url: 7 | collaborators: 8 | technical_evaluation: 9 | APIs: 10 | interface: 11 | background_workers: 12 | test_driven_development: 13 | process: 14 | client_satisfaction: 15 | deployment: 16 | features: 17 | interface: 18 | concept: 19 | notes: 20 | group2: 21 | app_name: "snowcial" 22 | members: 23 | repo_url: 24 | production_url: 25 | collaborators: 26 | technical_evaluation: 27 | APIs: 28 | interface: 29 | background_workers: 30 | test_driven_development: 31 | process: 32 | client_satisfaction: 33 | deployment: 34 | features: 35 | interface: 36 | concept: 37 | notes: 38 | group3: 39 | app_name: "successive life" 40 | members: Tan Doan, Bobbie Gu, ERic Fransen, Gus 41 | repo_url: https://github.com/ericfransen/successive_life 42 | production_url: https://104.236.2.42 43 | collaborators: 44 | technical_evaluation: 45 | APIs: 46 | interface: 47 | background_workers: 48 | test_driven_development: 49 | process: 50 | client_satisfaction: 51 | deployment: 52 | features: 53 | interface: 54 | concept: 55 | notes: 56 | group4: 57 | app_name: "tunefish" 58 | members: 59 | repo_url: 60 | production_url: 61 | collaborators: 62 | technical_evaluation: 63 | APIs: 64 | interface: 65 | background_workers: 66 | test_driven_development: 67 | process: 68 | client_satisfaction: 69 | deployment: 70 | features: 71 | interface: 72 | concept: 73 | notes: 74 | 75 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/daughter_of_store_engine.rb: -------------------------------------------------------------------------------- 1 | # Add your git repo URL and 2 | # one or more collaborator accounts for push access 3 | 4 | def project 5 | { 6 | :gates => {:repo => 'git://github.com/jmejia/daughter_of_store_engine.git', 7 | :collaborators => ['e.b.drummond@gmail.com', 'jen7maples@gmail.com', 'novohispano@gmail.com', 'joshua.mejia@gmail.com']}, 8 | :ellison => {:repo => 'git@github.com:philbattos/daughter_of_store_engine.git', 9 | :collaborators => ['jemaddux@gmail.com', 'pnblackwell@gmail.com', 'philbattos@gmail.com', 'blair81@gmail.com']}, 10 | :woz => {:repo => 'https://github.com/bradpsheehan/daughter_of_store_engine.git', 11 | :collaborators => ['danmee10@gmail.com', 12 | 'denmanjd@gmail.com', 13 | 'bradpsheehan@gmail.com', 14 | 'chrisknight.mail@gmail.com']}, 15 | :jobs => {:repo => 'git@github.com:raphweiner/daughter_of_store_engine.git', 16 | :collaborators => [ 17 | 'gschorkopf@gmail.com', 18 | 'raphael.weiner@gmail.com', 19 | 'chelsea.komlo@gmail.com', 20 | 'rogerssh@tcd.ie']}, 21 | :ballmer => {:repo => 'git://github.com/kylesuss/daughterofstore_engine.git', 22 | :collaborators => [ 23 | 'lalalainexd@gmail.com.com', 24 | 'susskyle@gmail.com', 25 | 'aimeegirl723@gmail.com', 26 | 'lauramsteadman@gmail.com']}, 27 | :allen => {:repo => 'git://github.com/kareemgrant/daughterofstore_engine.git', 28 | :collaborators => ['dannygarcia.me@gmail.com', 'lsears322@gmail.com', 'kareem@getuserwise.com']} 29 | } 30 | end 31 | 32 | def config 33 | {:abbreviation => 'dose'} 34 | end 35 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/chambers_jonmichael.markdown: -------------------------------------------------------------------------------- 1 | ### Untitled. :( 2 | 3 | #### Pitch 4 | 5 | Competitive eSports is quickly growing market, but users aren't always able to view livestreams of matches. This project seeks to solve that problem by providing match updates to users via SMS and a web based interface. 6 | 7 | #### Description 8 | 9 | While companies like Riot Games and Valve have really pushed the limits of competitive eSports with massive prize pools and amazing venues (Staples Center, World Cup Stadium in Korea), live coverage of competitive matches outside of watching the stream itself is very much lacking. 10 | 11 | The idea of this project is to use image / pattern recognition to determine what events are happening within a given match, and to provide that information to users who may not be able to actively watch a live game. 12 | 13 | I plan to start with League of Legends, but there is no reason that this service couldn't expand to support other competitve games like Dota 2. 14 | 15 | #### Target Audience 16 | 17 | Gamers. 18 | 19 | #### Integrations 20 | 21 | * Twitch.tv is the most obvious candidate for oAuth integration. The majority of competitive streams are displayed on Twitch.tv, so the bulk of the target audience likely already have Twitch.tv accounts. 22 | * None of the data.gov APIs are very thrilling. I was planning on pulling data from the somewhat less public APIs from the League of Legends eSport site (as it's built with Angular and has JSON endpoints) in addition to the official Riot Games API (for item, champion, and other information in various languages). 23 | * I was planning on using Twilio, and if time permits, making use of the Ruboto gem to -perhaps- create an Android app to interact with the application. Oh, and maybe Pusher for real time messaging. I've rolled my own solution before using Redis, so it'd be nice to let someone else handle it. 24 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/son_of_store_engine.markdown: -------------------------------------------------------------------------------- 1 | ## Son of Store Engine Submissions 2 | 3 | Original project description at http://tutorials.jumpstartlab.com/projects/son_of_store_engine.html 4 | 5 | Submissions are due at 9:00AM MT on 4/18/13. 6 | 7 | ## Production & Repositories 8 | 9 | ### Example 10 | 11 | #### Mr. Black: Jeff Casimir, Katrina Owen, Franklin Webber 12 | 13 | * Production URL: http://mrblack.herokuapp.com 14 | * Repository: http://github.com/jcasimir/son_of_store_engine 15 | * Extensions: Subdomains, CSS/Themes 16 | 17 | ### Student Submissions 18 | 19 | #### Mr. White: Bradley Sheehan, Paul Blackwell, Jorge Tellez, Raphael Weiner 20 | 21 | * Production URL: http://mrwhite-sose.herokuapp.com 22 | * Repository: https://github.com/raphweiner/son_of_store_engine.git 23 | * Extensions: 24 | 25 | #### Mr. Blonde: Aimee Maher, Danny Garcia, Chelsea Komlo, John Maddux 26 | 27 | * Production URL: http://mrblonde.herokuapp.com/ 28 | * Repository: http://github.com/jemaddux/son_of_store_engine 29 | * Extensions: 30 | 31 | #### Mr. Orange: Kareem Grant, James Denman, Kyle Suss, Shane Rogers 32 | 33 | * Production URL: http://shopmazing.herokuapp.com/ 34 | * Repository: https://github.com/phoenixbox/sonofstore_engine 35 | * Extensions: 36 | 37 | #### Mr. Pink: Geoffrey Schorkopf, Erin Drummond, Laura Steadman, Daniel Mee 38 | 39 | * Production URL: http://pink-sose.herokuapp.com/ 40 | * Repository: http://github.com/gschorkopf/sonofstore_engine 41 | * Extensions: 42 | 43 | #### Mr. Brown: Christopher Knight, Blair Anderson, Jennifer Eliuk, Logan Sears 44 | 45 | * Production URL: http://sonofsam.herokuapp.com/ 46 | * Repository: https://github.com/blairanderson/sonofstore_engine 47 | * Extensions: 48 | 49 | #### Mr. Blue: Phil Battos, Josh Mejia, Elaine Tai 50 | 51 | * Production URL: http://epicsale.herokuapp.com/ 52 | * Repository: https://github.com/lalalainexd/son_of_store_engine 53 | * Extensions: 54 | -------------------------------------------------------------------------------- /1410/07_dinner_dash/dinner_dash_submissions.yml: -------------------------------------------------------------------------------- 1 | Chris, Brandon, Laura, Bhargavi: 2 | repository: "https://github.com/bhargavisatpathy/dinner_dash" 3 | setup_notes: 4 | instructor_evaluation: "all features working -- admin dashboard not protected, would be nice to see flash errors when not passing validations." 5 | notes: 6 | rubric: 7 | Feature Completeness: 2 8 | Views: 3 9 | Controllers: 3 10 | Models: 3 11 | TDD: 3 12 | Usability: 3 13 | Workflow: 4 14 | 15 | Bryce, Rich, Alex, Kit: 16 | repository: 17 | setup_notes: 18 | instructor_evaluation: "most base expectations fulfilled; can view all orders regardless of authentication status and authorization; would like to see better error messages for invalid form submissions; user interface is kind of strange; cart doesn't clear when logging out and logging back in as admin." 19 | notes: 20 | rubric: 21 | Feature Completeness: 2 22 | Views: 3.5 23 | Controllers: 3 24 | Models: 3.5 25 | TDD: 3 26 | Usability: 2.5 27 | Workflow: 4 28 | 29 | Scott, Lydia, Orion, Jeff: 30 | repository: 31 | setup_notes: 32 | instructor_evaluation: 33 | notes: "all functionality implemented, pushed logic down the stack, good use of partials in views" 34 | rubric: 35 | Feature-completeness: 3 36 | Views: 4 37 | Controllers: 4 38 | Models: 4 39 | TDD: 3 40 | Usability: 4 41 | Workflow: 3 42 | 43 | Nathan, Krista, Mike, Emily: 44 | repository: 45 | setup_notes: 46 | instructor_evaluation: 47 | notes: "all base features implemented; can see other users' orders; " 48 | rubric: 49 | Feature Completeness: 3 50 | Views: 3 51 | Controllers: 4 52 | Models: 4 53 | TDD: 3 54 | Usability: 3.5 55 | Workflow: 4 56 | 57 | 58 | -------------------------------------------------------------------------------- /1409/06_the_pivot/submissions.yml: -------------------------------------------------------------------------------- 1 | TravelHome: 2 | url: http://travel-home.herokuapp.com 3 | repository: https://github.com/dalexj/da_pivot 4 | team_members: "Danny, Alex, Viki, Sam" 5 | instructor_evaluation: 6 | notes: "Polished product. Showed good project management skills. Nice UX." 7 | rubric: 8 | Feature Delivery: 9 | Completion: 3.5 10 | Organization: 4 11 | Progress: 4 12 | Technical Quality: 13 | Testing: 3 14 | Code Quality: 3.5 15 | UX: 3.5 16 | 17 | Kevaah: 18 | url: https://keevah-pivot.herokuapp.com 19 | repository: https://github.com/bayendor/the_pivot 20 | team_members: "David, Travis, Chase, Kate" 21 | instructor_evaluation: 22 | notes: "UX needed significant more work. Backend was nicely done. Test coverage was superb." 23 | rubric: 24 | Feature Delivery: 25 | Completion: 2.5 26 | Organization: 4 27 | Progress: 2.5 28 | Technical Quality: 29 | Testing: 4 30 | Code Quality: 3.5 31 | UX: 2 32 | 33 | AirLift: 34 | url: 35 | repository: https://airlyft.herokuapp.com 36 | team_members: "Adam, Greg, Chandra, Herbert" 37 | instructor_evaluation: 38 | notes: "Good UX, registration flow needed improvement. Solid code." 39 | rubric: 40 | Feature Delivery: 41 | Completion: 2.5 42 | Organization: 3.5 43 | Progress: 3 44 | Technical Quality: 45 | Testing: 1.5 46 | Code Quality: 3.5 47 | UX: 2.5 48 | 49 | EmployMe: 50 | url: http://www.larsonkonr.com 51 | repository: https://github.com/tmee/the-pivot 52 | team_members: "Konr, Tim, Zach" 53 | instructor_evaluation: 54 | notes: "UX needed major improvement. Testing was lacking. Their overall project management skills need improvement." 55 | rubric: 56 | Feature Delivery: 57 | Completion: 3 58 | Organization: 2.5 59 | Progress: 2 60 | Technical Quality: 61 | Testing: 1 62 | Code Quality: 2.5 63 | UX: 1.5 64 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/will_faurot.markdown: -------------------------------------------------------------------------------- 1 | Will Faurot 2 | 3 | #### Need to Have All 4 | 5 | √ You must use an external OAuth provider to authenticate users 6 | √ You must filter data appropriately in both the web and API based on authorization rules 7 | √ You must make use of a Virtual Private Server to host your application 8 | √ Make use of background workers for all appropriate tasks 9 | * Send notifications to users over email/SMS/Twitter 10 | 11 | #### Nice to Have 12 | 13 | x You must automate the deployment of your application to a single command 14 | x Your application must accept uploads of some user images 15 | x Your application must manipulate those images to suit the layout/style of the app itself 16 | x Receive some form of content from users via email 17 | 18 | √ In addition, your application **must make good use of one dataset or API from a public/non-profit non-partisan source such as:** 19 | (geocoder and sunlight labs) 20 | 21 | ### Rubric 22 | 23 | ### Feature Delivery 24 | 25 | You'll be graded on each of the criteria below with a score of 26 | (1) well below expectations 27 | (2) below expectations 28 | (3) as expected 29 | (4) better than expected 30 | 31 | (3) * Feature Completion: were the components you built well implemented? 32 | (3) * Project Completion: did you build enough features to realize the vision of a useful application? 33 | (3) * User Experience: (1) inattention to the user experience, (2) some gaps in the UX, (3) a production-ready user experience, (4) a polished UX 34 | 35 | 36 | ### Technical Quality 37 | 38 | (3.5) * Organization: did you use your project management tool to keep the project organized? 39 | (3) * Test-Driven Development: (1) disregard for testing, (2) gaps in test usage/coverage/design, (3) adequate testing, (4) exceptional use of testing 40 | (3.5) * Code Quality: (1) poor factoring and understanding of MVC, (2) some gaps in code quality / application of MVC, (3) solid code quality and pushing logic down the stack, (4) exceptionally well factored code 41 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/emily_davis.markdown: -------------------------------------------------------------------------------- 1 | Emily Davis 2 | 3 | 4 | #### Need to Have All 5 | 6 | √ You must use an external OAuth provider to authenticate users 7 | √ You must filter data appropriately in both the web and API based on authorization rules 8 | x You must make use of a Virtual Private Server to host your application 9 | √ Make use of background workers for all appropriate tasks 10 | √ Send notifications to users over email/SMS/Twitter 11 | 12 | #### Nice to Have 13 | 14 | x You must automate the deployment of your application to a single command 15 | x Your application must accept uploads of some user images 16 | x Your application must manipulate those images to suit the layout/style of the app itself 17 | x Receive some form of content from users via email 18 | 19 | #### Probably Skip 20 | 21 | x You must expose a JSON API that allows a user to both read and write data 22 | x You must create a Ruby gem which allows a user to easily interact with your API 23 | 24 | 25 | ### Rubric 26 | 27 | ### Feature Delivery 28 | 29 | You'll be graded on each of the criteria below with a score of 30 | (1) well below expectations 31 | (2) below expectations 32 | (3) as expected 33 | (4) better than expected 34 | 35 | (4) * Feature Completion: were the components you built well implemented? 36 | (3.5) * Project Completion: did you build enough features to realize the vision of a useful application? 37 | (3) * User Experience: (1) inattention to the user experience, (2) some gaps in the UX, (3) a production-ready user experience, (4) a polished UX 38 | 39 | 40 | ### Technical Quality 41 | 42 | (3) * Organization: did you use your project management tool to keep the project organized? 43 | (2) * Test-Driven Development: (1) disregard for testing, (2) gaps in test usage/coverage/design, (3) adequate testing, (4) exceptional use of testing 44 | (3) * Code Quality: (1) poor factoring and understanding of MVC, (2) some gaps in code quality / application of MVC, (3) solid code quality and pushing logic down the stack, (4) exceptionally well factored code 45 | -------------------------------------------------------------------------------- /1412/02_sales_engine/sales_engine_eval.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | Miriam Moser & Kyle Henson 3 | repository: 4 | evaluation: 5 | notes: | 6 | Assessor: Josh Mejia 7 | 1. Functional Expectations - 2 8 | 2. Test-Driven Development - 3 9 | 3. Encapsulation / Breaking Logic into Components - 4 10 | 4. Fundamental Ruby & Style - 3 11 | 5. Enumerable & Collections - 3 12 | 6. Code Sanitation - 3 13 | 14 | 15 | Lori Culberson & Kyra Weber 16 | repository: 17 | evaluation: 18 | notes: | 19 | Assessed by Josh Mejia 20 | 1. Functional Expectations - 2 21 | 2. Test-Driven Development - 3 22 | 3. Encapsulation / Breaking Logic into Components - 4 23 | 4. Fundamental Ruby & Style - 3 24 | 5. Enumerable & Collections - 4 25 | 6. Code Sanitation - 3 26 | 27 | 28 | David E Maurer & Stanley Siudzinski 29 | repository: 30 | evaluation: 31 | notes: | 32 | Assessed by Josh Mejia 33 | 1. Functional Expectations - 2 34 | 2. Test-Driven Development - 3 35 | 3. Encapsulation / Breaking Logic into Components - 4 36 | 4. Fundamental Ruby & Style - 3 37 | 5. Enumerable & Collections - 3 38 | 6. Code Sanitation - 2 39 | 40 | 41 | Austin Wood & Edward McCarthy 42 | repository: 43 | evaluation: 44 | notes: | 45 | Assessed by Josh Mejia 46 | 1. Functional Expectations - 2 47 | 2. Test-Driven Development - 3.5 48 | 3. Encapsulation / Breaking Logic into Components - 4 49 | 4. Fundamental Ruby & Style - 4 50 | 5. Enumerable & Collections - 3 51 | 6. Sanitation - 3 52 | 53 | 54 | Teresa Finn & Fred Block 55 | repository: 56 | evaluation: 57 | notes: | 58 | Assessed by Josh Mejia 59 | 1. Functional Expectations - 1 60 | 2. Test-Driven Development - 4 61 | 3. Encapsulation / Breaking Logic into Components - 3 62 | 4. Fundamental Ruby & Style - 3 63 | 5. Enumerable & Collections - 3 64 | 6. Sanitation - 2 65 | 66 | -------------------------------------------------------------------------------- /1409/05_dinner_dash/dinner_dash_submissions.yml: -------------------------------------------------------------------------------- 1 | Sam Herbert Yoder Tim 2 | repository: https://github.com/Tmee/Dinner-Dash 3 | setup_notes: "worked well" 4 | instructor_evaluation: 5 | notes: "Fullfills base expectations with 1 or 2 minor bugs 6 | Very Nice UI; site quite usable; starting to look like a real product" 7 | rubric: 8 | Feature Completeness: "Grudging 3; features are there but a ocuple small bugs" 9 | Views: 4 10 | Controllers: 3 11 | Models: 3 12 | TDD: 3 13 | Usability: 4 14 | 15 | 16 | 17 | Viki Greg Chase Konr 18 | repository: https://github.com/larsonkonr/dinner_dash 19 | setup_notes: "worked well" 20 | instructor_evaluation: 21 | notes: "Fullfills base expectations; 1 minor permission / auth issue with user updating 22 | UI is servicable but leaves too many default rails components in place " 23 | rubric: 24 | Feature Completeness: "Grudging 3; features are there but a ocuple small bugs" 25 | Views: 3 26 | Controllers: 3 27 | Models: 3.5 28 | TDD: 3.5 29 | Usability: 2 30 | 31 | 32 | 33 | Alex Chandra Kate Zach 34 | repository: https://github.com/chandracarney/dinner-dash 35 | setup_notes: "setup was fine" 36 | instructor_evaluation: 37 | notes: "Fullfills base expectations; JS search is a nice little bonus; functionality is simple but solid; code is similarly simple but solid" 38 | rubric: 39 | Feature Completeness: 3.2.to_i 40 | Views: 3 41 | Controllers: 3 42 | Models: 3 43 | TDD: 3 44 | Usability: 3.5 45 | 46 | Adam Smith & Danny Glunz & David Bayendor 47 | repository: https://github.com/dglunz/dinner_dash 48 | setup_notes: "setup was fine" 49 | instructor_evaluation: 50 | notes: "Solid app; UI is pleasant but simple; good functionality including a couple extensions; no issues running through features" 51 | rubric: 52 | Feature Completeness: 4 53 | Views: 4 54 | Controllers: 3 55 | Models: 3.5 56 | TDD: 3 57 | Usability: 3.5 58 | -------------------------------------------------------------------------------- /archive/1406/06_the_pivot/checkpoint_2.markdown: -------------------------------------------------------------------------------- 1 | Kevaah: 2 | Feature Delivery: 3 | * Notes 4 | * Features and UX are very rough 5 | * We have a lot of features that are 80% complete 6 | * Completion: 1 7 | * Organization: 2 8 | * Progress: 3 9 | Technical Progress: 10 | * Notes: 11 | * Great work reeling in the test suite 12 | * Some core interations are not feature tested (ie: checkout doesn't work) 13 | * Scores: 14 | * TDD: 3 15 | * Quality: 3 16 | * UX: 2 17 | EmployMe: 18 | Feature Delivery: 19 | * Notes 20 | * UX shows effort but is still rough 21 | * Some features are demoed that don't work (ie: search) 22 | * For a text-content driven site you need better formatting of user text 23 | * Doesn't feel like a week of progress 24 | * Raise your standards for what it means for code to get into the app 25 | * Scoring 26 | * Completion: 2 27 | * Organization: 2 28 | * Progress: 3 29 | Technical Progress: 30 | * Notes: 31 | * *master* tests have a few failures 32 | * only 35 tests 33 | * TDD still doesn't feels important 34 | * Scoring: 35 | * TDD: 1 36 | * Quality: 3 37 | * UX: 2 38 | Airlift: 39 | Feature Delivery: 40 | * Notes 41 | * Basic functionality is there 42 | * Light UX is in place 43 | * Features presented are implemented 44 | * Scoring 45 | * Completion: 3 46 | * Organization: 3 47 | * Progress: 3 48 | Technical 49 | * Notes 50 | * 130 tests that are all passing 51 | * Scores 52 | * TDD: 3 53 | * Quality: 3 54 | * UX: 3 55 | TravelHome: 56 | Feature Delivery: 57 | * Notes 58 | * Some very good UX on the front and secondary pages 59 | * Checkout flow is there and needs some refinement 60 | * Scoring 61 | * Completion: 3 62 | * Organization: 3 63 | * Progress: 3 64 | Technical: 65 | * Notes 66 | * 90 tests, 2 fail 67 | * Add test coverage 68 | * Tests are a bit brittle 69 | * Scoring 70 | * TDD: 2.5 71 | * Quality: 3? 72 | * UX: 3 73 | -------------------------------------------------------------------------------- /archive/gschool-0/reading/eloquent_ruby/rg2/group_1_notes.markdown: -------------------------------------------------------------------------------- 1 | ## RG2 Notes for Eloquent Ruby 2 | 3 | ### Short Methods (CH10) & Operators (CH11) & Equality (CH12) 4 | 5 | #### Key Ideas : 6 | * (CH10) Make your methods do one thing well 7 | * (CH11) Operators are built in methods 8 | * (CH12) Sing, dub, and trip equal signs. 9 | 10 | 11 | #### The Highlight : 12 | 13 | * The "===" actually calls the "==" method 14 | 15 | * Operators are really methods in disguise 16 | 17 | ``` 18 | Given: 19 | a = 1 20 | b = 2 21 | 22 | Then: 23 | a + b = 3 24 | 25 | is the same as 26 | 27 | a.+(b) = 3 28 | ``` 29 | 30 | #### The Lowlight : 31 | * Equality is still a confusing topic 32 | 33 | ___ 34 | 35 | ### Singletons (CH13) & Class Instance Variables (CH14) 36 | 37 | #### Key Ideas: 38 | 39 | * Create behaviors independant of the class 40 | * Describing the difference between class/instance variables 41 | 42 | #### The Highlight: 43 | 44 | * Class variable act like global variables 45 | 46 | 47 | #### The Lowlight: 48 | 49 | * When to create singletons? Practical uses. 50 | 51 | ___ 52 | 53 | ### Modules as Namespaces (CH15) & Mixins (CH16) 54 | 55 | #### Key Ideas: 56 | 57 | * Modules ability to contain code / use Module level methods 58 | * Can easily share code between un-related classes 59 | 60 | #### The Highlight: 61 | 62 | * Use Modules to avoid name collisions 63 | * Extending modules dramatically reduces repetition 64 | 65 | #### The Lowlight: 66 | 67 | * When should you start to formulate Modules (beggining or end) 68 | * How to make code less fragile when doing lots of extensions. 69 | 70 | --- 71 | 72 | ### Blocks (CH17) & Execute Around (CH18) & Execute Later (CH19) 73 | 74 | #### Key Ideas: 75 | 76 | * Can be used to iterate over 'chunks' of code 77 | * Gives you control over when to execute a block 78 | * Blocks can be saved as a variable 79 | 80 | #### The Highlight: 81 | 82 | * Blocks can iterate over more than collections. I.E. Strings 83 | 84 | 85 | #### The Lowlight: 86 | 87 | * Confusing because we have not practiced in actual code 88 | 89 | -------------------------------------------------------------------------------- /1407/06_the_pivot/submissions.rb: -------------------------------------------------------------------------------- 1 | def project 2 | { 3 | :group1 => { :app_name => 'airlift', 4 | :members => ['Jim Sutton', 'Jessica Goulding', 'Kavita'], 5 | :repo_url => 'https://github.com/JessicaG/the_pivot', 6 | :production_url=> 'http://airlifter.herokuapp.com/', 7 | :collaborators => ['jimsuttonjimsutton@gmail.com','jgoulding2@gmail.com'], 8 | :technical_evaluation => { 9 | :modeling => 0, 10 | :interface => 0, 11 | :performance => 0, 12 | :process => 0, 13 | :comments => "" 14 | } 15 | }, 16 | :group2 => { :app_name => 'dope_threads', 17 | :members => ['Ian Andersen', 'Glen Egbert', 'Rolando Naverrete'], 18 | :repo_url => 'https://github.com/glenegbert/the_pivot', 19 | :production_url=> 'https://young-ocean-9633.herokuapp.com/', 20 | :collaborators => ['ianderse@mac.com','kinglouis.belmont@gmail.com', 'glenegbert1@gmail.com'], 21 | :technical_evaluation => { 22 | :modeling => 0, 23 | :interface => 0, 24 | :performance => 0, 25 | :process => 0, 26 | :comments => "" 27 | } 28 | }, 29 | :group3 => { :app_name => 'gallery', 30 | :members => ['Aaron Wortham', 'Luke Aiken', 'Sarah Simon'], 31 | :repo_url => 'https://github.com/someproject.git', 32 | :production_url=> 'none', 33 | :collaborators => ['wortham.aaron@gmail.com', 'lukeaiken@gmail.com', 'smbsimon@gmail.com'], 34 | :technical_evaluation => { 35 | :modeling => 0, 36 | :interface => 0, 37 | :performance => 0, 38 | :process => 0, 39 | :comments => "" 40 | } 41 | } 42 | } 43 | end 44 | 45 | def config 46 | {:abbreviation => 'the_pivot'} 47 | end 48 | -------------------------------------------------------------------------------- /1412/03_traffic_spy/traffic_spy.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | Dustin, Paul, & Markus: 3 | repository: https://github.com/neslom/traffic-spy 4 | setup_notes: "" 5 | instructor_evaluation: 6 | notes: "Fulfills all base expectations. Well tested. Use of 'serialize' PORO to encapsulate logic." 7 | rubric: 8 | Functional Expectations: 3 9 | Test-Driven Development: 4 10 | Encapsulation / Components: 3 11 | Fundamental Ruby & Style: 3 12 | Sinatra / Web and Business Logic: 2.5 13 | View Layer: 3 14 | Miriam Moser & Edward McCarthy & Jeffrey Gu: 15 | repository: 16 | setup_notes: "" 17 | instructor_evaluation: 18 | notes: "All but one tiny thing fulfilled in base expectations. Break out view logic into partial." 19 | rubric: 20 | Functional Expectations: 3 21 | Test-Driven Development: 2 22 | Encapsulation / Components: 3 23 | Fundamental Ruby & Style: 2.5 24 | Sinatra / Web and Business Logic: 3 25 | View Layer: 2 26 | Austin Wood & Kyra Steenbock & Lori Culberson: 27 | repository: 28 | setup_notes: "Some missing base functionality. " 29 | instructor_evaluation: 30 | notes: 31 | rubric: 32 | Functional Expectations: 2 33 | Test-Driven Development: 2 34 | Encapsulation / Components: 3 35 | Fundamental Ruby & Style: 2 36 | Sinatra / Web and Business Logic: 3 37 | View Layer: 3 38 | Teresa Finn & DJ Greenfield & Trey Tomlinson: 39 | repository: 40 | setup_notes: "" 41 | instructor_evaluation: 42 | notes: 43 | rubric: 44 | Functional Expectations: 1 45 | Test-Driven Development: 2 46 | Encapsulation / Components: 2.5 47 | Fundamental Ruby & Style: 1 48 | Sinatra / Web and Business Logic: 2.5 49 | View Layer: 2.5 50 | Fred Block & Stanley Siudzinski & Charles Valentino Espinoza: 51 | repository: 52 | setup_notes: "" 53 | instructor_evaluation: 54 | notes: 55 | rubric: 56 | Functional Expectations: 1.5 57 | Test-Driven Development: 2.5 58 | Encapsulation / Components: 2.5 59 | Fundamental Ruby & Style: 2.5 60 | Sinatra / Web and Business Logic: 2.5 61 | View Layer: 2.5 62 | 63 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/allison_larson.markdown: -------------------------------------------------------------------------------- 1 | Allison Larson 2 | 3 | #### Need to Have All 4 | 5 | √ You must use an external OAuth provider to authenticate users 6 | √ You must filter data appropriately in both the web and API based on authorization rules 7 | √ You must make use of a Virtual Private Server to host your application 8 | √ Make use of background workers for all appropriate tasks 9 | √ Send notifications to users over email/SMS/Twitter 10 | 11 | #### Nice to Have 12 | 13 | Try for at least one of these: 14 | 15 | x You must automate the deployment of your application to a single command 16 | √ Your application must accept uploads of some user images 17 | √ Your application must manipulate those images to suit the layout/style of the app itself 18 | √ Receive some form of content from users via email 19 | 20 | #### Probably Skip 21 | 22 | √ You must expose a JSON API that allows a user to both read and write data 23 | √/2 You must create a Ruby gem which allows a user to easily interact with your API 24 | 25 | 26 | √ In addition, your application **must make good use of one dataset or API from a public/non-profit non-partisan source such as:** 27 | Colorado neighbourhood data and 4square api 28 | 29 | ### Rubric 30 | 31 | ### Feature Delivery 32 | 33 | You'll be graded on each of the criteria below with a score of 34 | (1) well below expectations 35 | (2) below expectations 36 | (3) as expected 37 | (4) better than expected. 38 | 39 | (3.5) * Feature Completion: were the components you built well implemented? 40 | (3) * Project Completion: did you build enough features to realize the vision of a useful application? 41 | (2) * User Experience: (1) inattention to the user experience, (2) some gaps in the UX, (3) a production-ready user experience, (4) a polished UX 42 | 43 | 44 | ### Technical Quality 45 | 46 | (3) * Organization: did you use your project management tool to keep the project organized? 47 | (3-) * Test-Driven Development: (1) disregard for testing, (2) gaps in test usage/coverage/design, (3) adequate testing, (4) exceptional use of testing 48 | (3) * Code Quality: (1) poor factoring and understanding of MVC, (2) some gaps in code quality / application of MVC, (3) solid code quality and pushing logic down the stack, (4) exceptionally well factored code 49 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/andy_mention.markdown: -------------------------------------------------------------------------------- 1 | Andy Mention 2 | In this individual project your big goals are to: 3 | 4 | #### Need to Have All 5 | 6 | x You must use an external OAuth provider to authenticate users 7 | x You must filter data appropriately in both the web and API based on authorization rules 8 | √/2 You must make use of a Virtual Private Server to host your application 9 | √ Make use of background workers for all appropriate tasks 10 | x Send notifications to users over email/SMS/Twitter 11 | 12 | #### Nice to Have 13 | 14 | x You must automate the deployment of your application to a single command 15 | √ Your application must accept uploads of some user images 16 | √ Your application must manipulate those images to suit the layout/style of the app itself 17 | x Receive some form of content from users via email 18 | 19 | #### Probably Skip 20 | 21 | √ You must expose a JSON API that allows a user to both read and write data 22 | x You must create a Ruby gem which allows a user to easily interact with your API 23 | 24 | ### Functional/Content Expectations 25 | 26 | √ In addition, your application **must make good use of one dataset or API from a public/non-profit non-partisan source such as:** 27 | 28 | 29 | ### Rubric 30 | 31 | ### Feature Delivery 32 | 33 | You'll be graded on each of the criteria below with a score of 34 | (1) well below expectations 35 | (2) below expectations 36 | (3) as expected 37 | (4) better than expected. 38 | 39 | (3) * Feature Completion: were the components you built well implemented? 40 | (2) * Project Completion: did you build enough features to realize the vision of a useful application? 41 | (2) * User Experience: (1) inattention to the user experience, (2) some gaps in the UX, (3) a production-ready user experience, (4) a polished UX 42 | 43 | 44 | ### Technical Quality 45 | 46 | (1) * Organization: did you use your project management tool to keep the project organized? 47 | (2) * Test-Driven Development: (1) disregard for testing, (2) gaps in test usage/coverage/design, (3) adequate testing, (4) exceptional use of testing 48 | (3) * Code Quality: (1) poor factoring and understanding of MVC, (2) some gaps in code quality / application of MVC, (3) solid code quality and pushing logic down the stack, (4) exceptionally well factored code 49 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/traffic_spy.markdown: -------------------------------------------------------------------------------- 1 | ## TrafficSpy Submissions 2 | 3 | Original project description at http://tutorials.jumpstartlab.com/projects/traffic_spy.html 4 | 5 | Submissions are due at 9:30AM MT on 3/7/13. 6 | 7 | ## Repositories 8 | 9 | * Each pair should submit the **Git Read-Only** URL for their project by submitting a pull request to this repo with the URL added below. 10 | * Modify *only* the line for your *Project URL* and the *Extensions* line right below it. 11 | * Non-conforming pull requests will be rejected 12 | * If your URL isn't merged by the deadline, your project will not be evaluated (aka it earns a `0`) 13 | 14 | ### Example 15 | 16 | * Jeff Casimir & Katrina Owen: 17 | * Project URL: git://github.com/jcasimir/traffic_spy.git 18 | * Extensions: Campaigns 19 | 20 | ### Student Submissions 21 | 22 | * Laura Steadman, Kareem Grant 23 | * Project URL: git://github.com/thesteady/traffic_spy.git 24 | * Extensions: Campaigns 25 | * John Maddux, Shane Rogers 26 | * Project URL: git@github.com:jemaddux/traffic_spy.git 27 | * Extensions: None 28 | * Logan Sears, James Denman 29 | * Project URL: git://github.com/jdendroid/traffic_spy.git 30 | * Extensions: None 31 | * Erin Drummond, Kyle Suss 32 | * Project URL: git://github.com/ebdrummond/traffic_spy.git 33 | * Extensions: Campaigns 34 | * Geoffrey Schorkopf, Bradley Sheehan 35 | * Project URL: git://github.com/gschorkopf/traffic_spy.git 36 | * Extensions: Campaigns 37 | * Paul Blackwell, Josh Mejia 38 | * Project URL: git://github.com/jmejia/traffic_spy.git 39 | * Extensions: None 40 | * Elaine Tai, Aimee Maher 41 | * Project URL: git://github.com/aimzatron/traffic_spy.git 42 | * Extensions: None 43 | * Phil Battos, Raphael Weiner 44 | * Project URL: git://github.com/raphweiner/traffic_spy.git 45 | * Extensions: All (campaigns, json, authentication) 46 | * Blair Anderson, Jorge Tellez 47 | * Project URL: git://github.com/novohispano/traffic_spy.git 48 | * Extensions: None 49 | * Chelsea Komlo, Christopher Knight 50 | * Project URL: git://github.com/chelseakomlo/traffic_spy.git 51 | * Extensions: none 52 | * Danny Garcia, Jennifer Eliuk 53 | * Project URL: git://github.com/danny-g/traffic_spy.git 54 | * Extensions: None 55 | * Ron Rateau, Daniel Mee 56 | * Project URL: git://github.com/danmee10/traffic_spy.git 57 | * Extensions: None 58 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/sales_engine.markdown: -------------------------------------------------------------------------------- 1 | ## SalesEngine Submissions 2 | 3 | Original project description at http://tutorials.jumpstartlab.com/projects/sales_engine.html 4 | 5 | Submissions are due at 10:30AM MT on 2/21/13 6 | 7 | ## Repositories 8 | 9 | * Each pair should submit the **Git Read-Only** URL for their project by submitting a pull request to this repo with the URL added below. 10 | * Modify *only* the line for your *Project URL* and the *Extensions* line right below it. 11 | * Non-conforming pull requests will be rejected 12 | * If your URL isn't merged by the deadline, your project will not be evaluated (aka it earns a `0`) 13 | 14 | ### Example 15 | 16 | * Jeff Casimir & Katrina Owen: 17 | * Project URL: git://github.com/gSchool/submissions.git 18 | * Extensions: Merchants, Invoices 19 | 20 | ### Student Submissions 21 | 22 | * Aimee Maher & Blair Anderson 23 | * Project URL: git://github.com/blairanderson/sales_engine.git 24 | * Extensions: None 25 | * Bradley Sheehan & Kareem Grant 26 | * Project URL: git://github.com/kareemgrant/sales_engine.git 27 | * Extensions: Merchant, Invoice 28 | * Christopher Knight & Danny Garcia 29 | * Project URL: git://github.com/danny-g/sales_engine.git 30 | * Extensions: none 31 | * Daniel Mee & Raphael Weiner 32 | * Project URL: git://github.com/raphweiner/sales_engine.git 33 | * Extensions: All 34 | * Jennifer Eliuk & Josh Mejia 35 | * Project URL: git://github.com/jmejia/sales_engine.git 36 | * Extensions: None 37 | * Jorge Tellez & Ron Rateau 38 | * Project URL: git://github.com/novohispano/sales_engine.git 39 | * Extensions: None 40 | * Kyle Suss & John Maddux 41 | * Project URL: git://github.com/jemaddux/sales_engine.git 42 | * Extensions: None 43 | * Laura Steadman & Elaine Tai 44 | * Project URL: git://github.com/lalalainexd/sales_engine.git 45 | * Extensions: None 46 | * Logan Sears & Chelsea Komlo 47 | * Project URL: git://github.com/Diasporism/sales_engine.git 48 | * Extensions: None 49 | * Paul Blackwell & James Denman 50 | * Project URL: git://github.com/jdendroid/sales_engine.git 51 | * Extensions: None 52 | * Phil Battos & Geoffrey Schorkopf 53 | * Project URL: git://github.com/gschorkopf/sales_engine.git 54 | * Extensions: None 55 | * Shane Rogers & Erin Drummond 56 | * Project URL: git://github.com/ebdrummond/sales_engine.git 57 | * Extensions: None 58 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/garreau_marc.markdown: -------------------------------------------------------------------------------- 1 | #### Career Crumbs v1, v2 2 | 3 | [If this project gets selected, put **SELECTED (v#)** here] 4 | 5 | #### Pitch 6 | 7 | We help job seekers get to where they want to go. 8 | 9 | #### Description 10 | 11 | [v1] Users can search our system for a job title and find the most frequently 12 | used words across many related job listings. With those words, they can 13 | view top amazon books related to that keyword, so that they spend time 14 | developing skills that companies want most. 15 | 16 | [v2] Users can search our system for a job title and view the many routes that 17 | people have taken to get that job. This relies on data with chronological 18 | listings of jobs from a source like the LinkedIn API. 19 | 20 | #### Target Audience 21 | 22 | This is aimed at anyone interested in a career change and wants to know more 23 | about how to be competitive for that next job. 24 | 25 | #### Integrations 26 | 27 | * [What OAuth provider makes sense for this audience?] 28 | LinkedIn 29 | * [What Data.gov data or API will you use?] 30 | LinkedIn or something from monster, indeed, glassdoor, etc. 31 | * [Any other integrations?] 32 | 33 | 34 | 35 | #### Career Crumbs v3 36 | 37 | [If this project gets selected, put **SELECTED (v#)** here] 38 | 39 | #### Pitch 40 | 41 | We help job seekers get to where they want to go. 42 | 43 | #### Description 44 | 45 | [Iteration 1] A user logs in with LinkedIn. Based on their location, the system displays 46 | high growth related job categories in their region (sourced from gov data). Clicking on one 47 | of the categories reveals related posts from glassdoor or whatever. 48 | 49 | [Iteration 2] A user can click on a job and see a comparison of their skills (as indicated 50 | on their LinkedIn profile or supplementally added) against required skills for a job. 51 | 52 | [Iteration 3] For those places where a user's skills are deficient, he/she can view which 53 | local institutions (tech schools, universities, etc) teach that skill. 54 | 55 | #### Target Audience 56 | 57 | This is aimed at anyone interested in a career change and wants to know more 58 | about how to be competitive for that next job. 59 | 60 | #### Integrations 61 | 62 | * [What OAuth provider makes sense for this audience?] 63 | LinkedIn 64 | * [What Data.gov data or API will you use?] 65 | Bureau of Labor Statistics, LinkedIn, Glassdoor or similar, etc. 66 | * [Any other integrations?] 67 | 68 | -------------------------------------------------------------------------------- /archive/1406/06_the_pivot/final_eval.markdown: -------------------------------------------------------------------------------- 1 | ## TravelHome 2 | 3 | ### Features & Functionality 4 | 5 | #### Notes 6 | 7 | * Good overall functionality 8 | * Good job dealing with dates and JavaScript which are each challenging 9 | * Some UX/design elements are rough, some are nice 10 | 11 | #### Scores 12 | 13 | * Completion: 3 14 | * Organization: 3 15 | * Progress: 3 16 | 17 | ### Technical 18 | 19 | #### Notes 20 | 21 | * 91 examples feels "ok" 22 | * Add test coverage tool 23 | 24 | #### Scores 25 | 26 | * TDD: 3 27 | * Code Quality: 3 28 | * User Experience: 3 29 | 30 | 31 | ## Airlift 32 | 33 | ### Features & Functionality 34 | 35 | #### Notes 36 | 37 | * Good functionality 38 | * Solid UX with rough edges 39 | * Feels like you have a lot of features 40 | * Well executed 41 | 42 | #### Scores 43 | 44 | * Completion: 3 45 | * Organization: 46 | * Progress: 4 47 | 48 | ### Technical 49 | 50 | #### Notes 51 | 52 | * 151 test, 10 pending, 141 passing 53 | * Test structures are strong, show good refactoring 54 | 55 | #### Scores 56 | 57 | * TDD: 4 58 | * Quality: 3 59 | * UX: 3 60 | 61 | ## EmployMe 62 | 63 | ### Features & Functionality 64 | 65 | * Job browsing experience is solid 66 | * Cart/checkout/submission a little confusing 67 | * Design overall strong 68 | * No resumes / no cover note is a big problem 69 | 70 | #### Scores 71 | 72 | * Completion: 2 73 | * Organization: 3 74 | * Progress: 2 75 | 76 | ### Technical 77 | 78 | * 56 examples, 1 pending 79 | * Controllers & models generally well put together 80 | * Not particularly stretching technical skils 81 | * Feature tests are generally well put together 82 | 83 | #### Scores 84 | 85 | * TDD: 3 86 | * Quality: 3 87 | * UX: 3 88 | 89 | ## For Next Time: 90 | 91 | * Move UX to Features, Organization to Technical 92 | 93 | ## Keevah 94 | 95 | ### Features & Functionality 96 | 97 | * UX has come a long way 98 | * Good overall flow 99 | * Some screens are a little rough 100 | * Copy is much better 101 | * Missing a platform admin kind of functionality 102 | 103 | #### Scores 104 | 105 | * Completion: 3 106 | * Organization: 3 107 | * Progress: 2.75 108 | 109 | ### Technical 110 | 111 | * Well put together for your current skill level 112 | * Needs some refactoring pushing logic down the stack 113 | * Watch out for "god" objects that attract too much functionality 114 | * Good testing 115 | * Look for opportunities to write unit tests 116 | 117 | #### Scores 118 | 119 | * TDD: 3 120 | * Quality: 3 121 | * UX: 3 122 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/evaluations/eric_fransen.markdown: -------------------------------------------------------------------------------- 1 | Eric Fransen 2 | 3 | 4 | #### Need to Have All 5 | 6 | √/2 You must use an external OAuth provider to authenticate users 7 | √ You must filter data appropriately in both the web and API based on authorization rules 8 | X You must make use of a Virtual Private Server to host your application 9 | √ Make use of background workers for all appropriate tasks 10 | x Send notifications to users over email/SMS/Twitter 11 | 12 | #### Nice to Have 13 | 14 | Try for at least one of these: 15 | 16 | x You must automate the deployment of your application to a single command 17 | x Your application must accept uploads of some user images 18 | x Your application must manipulate those images to suit the layout/style of the app itself 19 | x Receive some form of content from users via email 20 | 21 | #### Probably Skip 22 | 23 | x You must expose a JSON API that allows a user to both read and write data 24 | x You must create a Ruby gem which allows a user to easily interact with your API 25 | 26 | ### Functional/Content Expectations 27 | 28 | A good project idea should: 29 | 30 | x break down into logical iterations so that you can deliver a strong product on time 31 | √ be something that real people would want to use and find some utility for their life 32 | √ have enough *technical* challenge to be worth your time (as opposed to a *content* challenge) 33 | 34 | √ In addition, your application **must make good use of one dataset or API from a public/non-profit non-partisan source such as:** 35 | 36 | 37 | 38 | ### Feature Delivery 39 | 40 | You'll be graded on each of the criteria below with a score of (1) well below 41 | expectations, (2) below expectations, (3) as expected, (4) better than expected. 42 | 43 | (1) * Feature Completion: were the components you built well implemented? 44 | (2) * Project Completion: did you build enough features to realize the vision of a useful application? 45 | (2) * User Experience: (1) inattention to the user experience, (2) some gaps in the UX, (3) a production-ready user experience, (4) a polished UX 46 | 47 | 48 | ### Technical Quality 49 | 50 | (3) * Organization: did you use your project management tool to keep the project organized? 51 | (2) * Test-Driven Development: (1) disregard for testing, (2) gaps in test usage/coverage/design, (3) adequate testing, (4) exceptional use of testing 52 | (3) * Code Quality: (1) poor factoring and understanding of MVC, (2) some gaps in code quality / application of MVC, (3) solid code quality and pushing logic down the stack, (4) exceptionally well factored code 53 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/larson_allison.markdown: -------------------------------------------------------------------------------- 1 | ### Meet my neighbors. 2 | 3 | **SELECTED** 4 | 5 | #### Pitch 6 | 7 | Find the best local eating, venue, bar, etc in a Denver based on the neighborhood. 8 | 9 | #### Description 10 | 11 | Build your neighborhood community by knowing where to hang out with your neighbors. 12 | This app pulls neighborhood lines from http://data.denvergov.org/dataset/city-and-county-of-denver-statistical-neighborhoods 13 | and maps the best resturants, bars, parks, etc from 5280 with yelp ratings. 14 | Signing in with twitter also allows for tweets inviting your friends and seeing 15 | who is there. 16 | 17 | #### Target Audience 18 | 19 | Target audience would include travelers, new transplants, or people looking for 20 | their new favorite spot close by. 21 | 22 | #### Integrations 23 | 24 | * OAuth: Twitter authentication 25 | * APIs: Neighborhoods, Parks, Yelp API 26 | http://data.denvergov.org/dataset/city-and-county-of-denver-statistical-neighborhoods 27 | http://data.opencolorado.org/dataset/city-and-county-of-denver-parks 28 | * [Any other integrations?] 29 | 30 | 31 | ### Travel 32 | 33 | [If this project gets selected, put **SELECTED** here] 34 | 35 | #### Pitch 36 | 37 | Navigate a new city by walk/bike. 38 | 39 | #### Description 40 | 41 | This app would provide routes by bike or walk, and able to filter the route 42 | result based on speed, safety, landmarks, events, etc. It would provide ways of 43 | seeing a city that doesn't rely on having a car or spending money and time on a 44 | bus, but still allows for you to see the city that you're staying in for the 45 | amount of time that you are there. 46 | 47 | #### Target Audience 48 | 49 | Target audience would be travelers or people new to a city. 50 | 51 | #### Integrations 52 | 53 | * OAuth: Twitter authentication 54 | * APIs: Bike Paths, Sidewalks, Bike Stations, Bike Racks, Landmarks, Crime 55 | Reports, etc. 56 | 57 | 58 | ### Concert 59 | 60 | [If this project gets selected, put **SELECTED** here] 61 | 62 | #### Pitch 63 | 64 | See where your favorite artist is playing all over the world. 65 | 66 | #### Description 67 | 68 | This app would take user input from soundcloud or something similar to map the 69 | artist that a user has liked based on location of where their next concert is, 70 | allowing for a user to see where and when they can see music is or to help plan 71 | a trip around a concert or many concerts. 72 | 73 | #### Target Audience 74 | 75 | People who like to go to concerts. 76 | 77 | #### Integrations 78 | 79 | * OAuth: Soundcloud 80 | * APIs: Soundcloud, data scrape the internet? I don't know 81 | -------------------------------------------------------------------------------- /archive/gschool-0/reading/eloquent_ruby/rg2/group_6_notes.markdown: -------------------------------------------------------------------------------- 1 | ## RG2 Notes for Eloquent Ruby 2 | 3 | ### Short Methods (CH10) & Operators (CH11) & Equality (CH12) 4 | 5 | #### Key Ideas 6 | - Keep each class and method focused and readable. 7 | - Short and focused methods are readable to humans and reusable. 8 | - Single responsibility is better than multi-responsibility, or methods that do 10 things. 9 | - How to create and implement operators for classes. 10 | - Operators are really just methods. 11 | - Differentiating the different types of equality 12 | 13 | #### The Highlight 14 | - Being able to make your own iterators- blew our minds. 15 | - Keeping code clean saves later anguish when things break. 16 | - Operating across classes was helpful 17 | - Way of representing powerful things with very simple operators, but you have to really think about how it is going to be used. 18 | - Operators can be easy to try to use... 19 | 20 | #### The Lowlight 21 | - Not much of a lowlight specifically. 22 | - Just getting comfortable with this way of writing- keeping code clean and simple. 23 | - But operators can be difficult in actual implementation. 24 | - But operators can be difficult in actual implementation. 25 | 26 | 27 | ### Singletons (CH13) & Class Instance Variables (CH14) 28 | 29 | #### Key Ideas 30 | - Singleton methods can be used on a class, which is a single instance. 31 | - Idea of an invisible class which is actually there- reminder that everything is an object in Ruby. 32 | 33 | #### The Highlight 34 | - Clarified why we use self., class methods. 35 | - The example of the printer with the class instance variable chapter was helpful to clarify the chapter. 36 | - Subclasses was well-defined in this chapter. 37 | 38 | #### The Lowlight 39 | - New idea to try to understand- singletons. 40 | - Rails examples are hard to understand. 41 | 42 | ### Modules as Namespaces (CH15) & Mixins (CH16) 43 | 44 | #### Key Ideas 45 | - How to change a program on the fly. 46 | 47 | #### The Highlight 48 | - Understanding how to use mixens and modules in an effective way. 49 | - How to create a module that can get mixed in across classes. 50 | 51 | #### The Lowlight 52 | - How to change a program during runtime. 53 | 54 | ### Blocks (CH17) & Execute Around (CH18) & Execute Later (CH19) 55 | 56 | #### Key Ideas 57 | - Using blocks for recursive blocks 58 | 59 | #### The Highlight 60 | - The description of the "iterator on steroids" 61 | 62 | #### The Lowlight 63 | - Blocks feel unconfortable and unnatural! 64 | - Still unsure about their best use. 65 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/davis_emily.markdown: -------------------------------------------------------------------------------- 1 | ### Idea One: Best Snow. Best Go. 2 | 3 | **SELECTED** 4 | 5 | # Pitch 6 | This app will aggregate snowfall and travel data. 7 | 8 | # Description 9 | When a user opens the app, it will give them either: 10 | - Previously selected 'favorite' resorts sorted by travel time or snowfall in 11 | the last seven days 12 | - The three nearest mountains based on current travel time and prioritized by 13 | snowfall in the last seven days 14 | - There will also be a Twitter RSVP integration 15 | 16 | Two things define a weekend warrior's life: snowfall and traffic jams. I think 17 | this app would give that group a bit more power when planning their weekends. 18 | 19 | # Target Audience 20 | This app would appeal mostly to the weekend warriors of Colorado. 21 | 22 | # Integrations 23 | * OAuth Provider: Twitter 24 | * Data.gov: https://catalog.data.gov/dataset/daily-u-s-snow-monitoring 25 | * Twilio for text notifications? 26 | 27 | 28 | ############################################################################### 29 | 30 | 31 | ### Idea Two: Yes. You have homework. 32 | 33 | [If this project gets selected, put **SELECTED** here] 34 | 35 | #### Pitch 36 | This app would simplify communication between teachers and students. 37 | 38 | #### Description 39 | * The teacher can update a class calendar with homework assignments 40 | * The teacher can send 'task reminders' that would appear as notifications for 41 | students 42 | * Message board for questions and answers 43 | * Students would also be able to send teacher questions via messaging center 44 | * Links to assignments/resources 45 | 46 | Typically all these lines of communication are separated out into three different 47 | places. I think boiling it down to one would greatly improve student/teacher 48 | communication. 49 | 50 | #### Target Audience 51 | This app would appeal to teachers who want to simplify teacher-student 52 | communication lines. 53 | 54 | #### Integrations 55 | * OAuth Provider: Google (most schools provide teachers and students with a 56 | Google account) 57 | * Data.gov: Education 58 | * Twilio 59 | * Google Docs 60 | 61 | ### Idea Three: Daily Muchness 62 | 63 | [If this project gets selected, put **SELECTED** here] 64 | 65 | #### Pitch 66 | This app would send you a daily inspirational quote, and then offer you a place 67 | to plan your day from a positive aspect. 68 | 69 | #### Description 70 | * Automatically sends a daily inspirational quote via text or email 71 | * When the app is opened it will ask you to enter a goal for the day, list 72 | something that you're inspired by, etc. 73 | * Syncs with your calendar to give you a run down of your day 74 | * To-do list 75 | * At the end of the day it prompts you to enter a brief sum-up of your day 76 | 77 | #### Target Audience 78 | I imagine this app would appeal to women in the 20s - 30s. 79 | 80 | #### Integrations 81 | * OAuth Provider: Facebook or Twitter 82 | * Data.gov: Weather 83 | * Twilio, Instagram 84 | -------------------------------------------------------------------------------- /archive/gschool-0/reading/eloquent_ruby/rg2/group_3_notes.markdown: -------------------------------------------------------------------------------- 1 | ## RG2 Notes for Eloquent Ruby 2 | 3 | ### Short Methods (CH10) & Operators (CH11) & Equality (CH12) 4 | 5 | #### Key Ideas 6 | - Methods should only be focused on doing one thing. 7 | - Method names should be descriptive. 8 | - Overriding operators is dangerous business, specifically because of ordering. 9 | - 4 different ways of measuring equality. 10 | 11 | #### The Highlight 12 | - Understanding the four different equalities and where they are used will help save time down the road. 13 | - Didn't know we could override operators. 14 | 15 | #### The Lowlight 16 | - Triple equals still kind of fuzzy. 17 | - The application of defining new operators sounds really complicated (and kind of unnecessary). 18 | 19 | ### Singletons (CH13) & Class Instance Variables (CH14) 20 | 21 | #### Key Ideas 22 | - Class method is really a singleton. 23 | - Don't use a class variable when you can use a class instance variable. 24 | 25 | #### The Highlight 26 | - Didn't understand before how a class variable worked. 27 | - Singleton class is a hidden class - didn't know that. 28 | - As complexity of apps grow, we might be tempted to use class variables, but instance variables will work better - 29 | especially with multiple people working on the same project; don't want to override each others' work. 30 | 31 | #### The Lowlight 32 | - Still don't understand if class variables where class variables will EVER be a good idea. 33 | 34 | ### Modules as Namespaces (CH15) & Mixins (CH16) 35 | 36 | #### Key Ideas 37 | - Modules as namespaces work as a wrapper - a place for your stuff. 38 | - Modules can be treated as objects and sent to variables for future use. 39 | - Can include both instance and class methods within a mixin module. 40 | 41 | #### The Highlight 42 | - Modules as namespaces makes it easy to work with other programs that are likely to have the same class names. 43 | - Really neat to see how many methods you can utilize across classes by using mixin modules. 44 | - Can use kind_of? to identify included modules since they're part of the inheritance tree. 45 | 46 | #### The Lowlight 47 | - Kind of confused over include and extend. 48 | - You can extend a module by wrapping an include in a singleton - can be confusing. 49 | 50 | ### Blocks (CH17) & Execute Around (CH18) & Execute Later (CH19) 51 | 52 | #### Key Ideas 53 | - Blocks can take a lot of the repetition out of your code. 54 | - You can save blocks and execute them later - lazy initialization. Kind of like rspec mock. 55 | 56 | #### The Highlight 57 | - Nice to be already acquainted with enumerators - will save a ton of time. 58 | - each_cons pulls out two things at a time. 59 | - Hadn't really been exposed to blocks as parameters - implicit and explicit. 60 | - Execute around used everywhere in Rails. 61 | 62 | #### The Lowlight 63 | - Chapters 18 and 19 were confusing - won't really know how they're used until we practice them. 64 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/smith_alan.markdown: -------------------------------------------------------------------------------- 1 | ### Farm to Table 2 | 3 | [If this project gets selected, put **SELECTED** here] 4 | 5 | #### Pitch 6 | 7 | [1 sentence that explains the value proposition of the application. How would 8 | you explain it to a potential business partner, team member, or investor?] 9 | 10 | This app provides everything you need to know about Colorado farmers markets. 11 | 12 | #### Description 13 | 14 | The app uses open farmers market data for map location, directions, and information about the market. It also allows users to join friends and add events to their calendar. 15 | 16 | #### Target Audience 17 | 18 | Anyone who enjoyes locally grown food. 19 | 20 | #### Integrations 21 | 22 | * [What OAuth provider makes sense for this audience?] 23 | Google 24 | 25 | * [What Data.gov data or API will you use?] 26 | https://data.colorado.gov/Agriculture/Farmers-Market-Locations-2014/u8tu-wbbg 27 | 28 | * [Any other integrations?] 29 | Google maps 30 | -------------------------------------------------------------------------------------- 31 | 32 | ###GetAhead 33 | [If this project gets selected, put **SELECTED** here] 34 | 35 | #### Pitch 36 | 37 | Comprehensive information on Head Start programs in Denver 38 | 39 | #### Description 40 | 41 | This app provides comprehensive information about headstart programs in data. It has mapping information, services, ect. Users can rank locations, keep a queue of favorites, and apply. 42 | 43 | #### Target Audience 44 | 45 | Parents of young children looking for solid educational programs 46 | 47 | #### Integrations 48 | 49 | * [What OAuth provider makes sense for this audience?] 50 | Google 51 | 52 | * [What Data.gov data or API will you use?] 53 | http://data.opencolorado.org/dataset/city-and-county-of-denver-head-start-programs/resource/6c727941-cbb6-465d-8a85-804b375cff46 54 | 55 | * [Any other integrations?] 56 | Google maps 57 | -------------------------------------------------------------------------------------- 58 | 59 | ### Sherpa 60 | 61 | [If this project gets selected, put **SELECTED** here] 62 | 63 | #### Pitch 64 | 65 | [1 sentence that explains the value proposition of the application. How would 66 | you explain it to a potential business partner, team member, or investor?] 67 | 68 | Sherpa is your one stop trail guide for the Boulder area. 69 | 70 | #### Description 71 | 72 | The app uses google earth api along with public trail data to provide comprehensive trail information for the Boulder area (possibly other areas if I can find the info). Users can join friends for a hike, and plan/add events to their calendar. There will also be weather integration. 73 | 74 | #### Target Audience 75 | 76 | Anyone wanting to enjoy the outdoors. 77 | 78 | #### Integrations 79 | 80 | * [What OAuth provider makes sense for this audience?] 81 | Google 82 | 83 | * [What Data.gov data or API will you use?] 84 | https://bouldercolorado.gov/open-data/city-of-boulder-osmp-trails/ 85 | 86 | * [Any other integrations?] 87 | Google maps/Google earth 88 | Forecast io 89 | 90 | -------------------------------------------------------------------------------- /archive/gschool-0/projects/event_reporter.markdown: -------------------------------------------------------------------------------- 1 | ## EventReporter Submissions 2 | 3 | Original project description at http://tutorials.jumpstartlab.com/projects/event_reporter.html 4 | 5 | Submissions are due at 11AM MT on 2/7/13 6 | 7 | ## Repositories 8 | 9 | Each student should submit the "Git Read-Only" URL for their project by submitting a pull request to this repo with the URL added below. Modify *only* the line with your name and the "Extensions" line right below it. 10 | 11 | ### Example 12 | 13 | * Jeff Casimir: git://github.com/gSchool/submissions.git 14 | * Extensions: Improving Find, Implementing Queue Math 15 | 16 | ### Student Submissions 17 | 18 | * Blair Anderson: git://github.com/blairanderson/event_reporter_final.git 19 | * Extensions: Improving queue print, Improving queue save to 20 | * Paul Blackwell: git://github.com/pnblackwell/event_reporter.git 21 | * Extensions: 22 | * Phil Battos: https://github.com/philbattos/Event_Reporter/blob/master/event_reporter.rb 23 | * Extensions: 24 | * Erin Drummond: git://github.com/ebdrummond/gschool_event_reporter.git 25 | * Extensions: none 26 | * James Denman: git://github.com/jdendroid/event_reporter.git 27 | * Extensions: case insensitive find, formatted print per longest item 28 | * Jennifer Eliuk: git://github.com/7maples/event_reporter.git 29 | * Extensions: 30 | * Danny Garcia: git://github.com/danny-g/event_reporter.git 31 | * Extensions: find is case insensitive 32 | * Kareem Grant: git://github.com/kareemgrant/event_reporter.git 33 | * Extensions: Improving queue print, Improving find 34 | * Christopher Knight: git://github.com/SerKnight/event_reporter.git 35 | * Extensions: 36 | * Chelsea Komlo: git://github.com/ckoml/Event_Reporter_2.2013_CHK.git 37 | * Extensions: 38 | * John Maddux: git://github.com/jemaddux/Event_Reporter.git 39 | * Extensions: improving print, improving find 40 | * Aimee Maher: git://github.com/aimzatron/event_reporter.git 41 | * Extensions: 42 | * Josh Mejia: https://github.com/jmejia/event_reporter 43 | * Extensions: 44 | * Daniel Mee: git://github.com/danmee10/eventreporter.git 45 | * Extensions: 46 | * Ron Rateau: git://github.com/ronra/event_reporter.git 47 | * Extensions: 48 | * Shane Rogers: git@github.com:phoenixbox/event_reporter_final.git 49 | * Extensions: improved queue print 50 | * Laura Steadman: git://github.com/thesteady/gschool-event-reporter.git 51 | * Extensions: 52 | * Geoffrey Schorkopf: git@github.com:gschorkopf/event_reporter.git 53 | * Extensions: Improving queue print, Improving find, Implementing Queue Math 54 | * Kyle Suss: https://github.com/kylesuss/event-reporter.git 55 | * Extensions: 56 | * Logan Sears: git://github.com/Diasporism/event_reporter.git 57 | * Extensions: 58 | * Bradley Sheehan: git://github.com/bradpsheehan/event_reporter.git 59 | * Extensions: 60 | * Elaine Tai: git://github.com/lalalainexd/event-reporter.git 61 | * Extensions: 62 | * Jorge Tellez: git://github.com/novohispano/event_reporter.git 63 | * Extensions: Base Expectations only 64 | * Raphael Weiner: git://github.com/raphweiner/event_reporter.git 65 | * Extensions: All 66 | -------------------------------------------------------------------------------- /1409/04_clone_wars/clone_wars_submissions.yml: -------------------------------------------------------------------------------- 1 | --- 2 | submissions: 3 | Sam Kuhlmann & Alex Jensen & David Bayendor: 4 | repository: https://github.com/bayendor/clonewars_novo/ 5 | evaluation: 6 | notes: "Well constructed, good attention to details. DB logic well encapsulated, reasonable test coverage. Some template subdivision / extraction. Admin side works well, integrates well with the rest of the site. Could have pushed a little harder on schema complexity but this is my only real critique" 7 | Functional Expectations: 3 8 | Test Driven Development: 3 9 | Breaking Logic into Components: 3.5 10 | Fundamental Ruby & Style: 3.5 11 | Sinatra / Web and Business Logic: 4 12 | View Layer: 3.5 13 | submissions: 14 | Danny Glunz & Kate Lane & Herbert Joseph 15 | repository: https://github.com/dglunz/clonewars 16 | evaluation: 17 | notes: "Decent recreation of existing site. Many components are half finished unfortunately -- file uploading, email form, updating some of admin pages. Would have been good to see more consolidation around the core 'primitive' of the pages and how they are edited and displayed. Would be good to have multiple tables and more organization around what components make up a page." 18 | Functional Expectations: 2 19 | Test Driven Development: 3 20 | Breaking Logic into Components: 2 21 | Fundamental Ruby & Style: 2 22 | Sinatra / Web and Business Logic: 2 23 | View Layer: 2 24 | submissions: 25 | Travis Yoder & Zach Routhier & Chase Van Hekken 26 | repository: https://github.com/ChasevanHekken/clone_wars 27 | evaluation: 28 | notes: "good use of multiple tables with foreign keys; admin update functionality works well; good recreation of existing site. Tests are nonexistant. Views could use some extraction - lots of repeated markup for elements like nav etc;" 29 | Functional Expectations: 3 30 | Test Driven Development: 0 31 | Breaking Logic into Components: 3 32 | Fundamental Ruby & Style: 2.5 33 | Sinatra / Web and Business Logic: 3 34 | View Layer: 2 35 | submissions: 36 | Timothy Mee & Gregory Narajka & Konr Josef Laron 37 | repository: https://github.com/Tmee/Clone-Wars---Jimmy-s 38 | evaluation: 39 | notes: "Code looked pretty solid. Did three extensions. Tests checked for info on page but failed to interact with page elements. Database logic could have been split up better. Ruby looked good." 40 | Functional Expectations: 4 41 | Test Driven Development: 1.5 42 | Breaking Logic into Components: 3 43 | Fundamental Ruby & Style: 3.5 44 | Sinatra / Web and Business Logic: 3 45 | View Layer: 3 46 | submissions: 47 | Chandra Carney & Adam Smith & Victoria Harrod 48 | repository: https://github.com/VikiAnn/backcountry-deli-clone-wars 49 | evaluation: 50 | notes: "No tests. Code was headed in the right direction and the group knew what to do, but seemed to run out of time. Code written at the end is much nicer." 51 | Functional Expectations: 3 52 | Test Driven Development: 1 53 | Breaking Logic into Components: 2.5 54 | Fundamental Ruby & Style: 3 55 | Sinatra / Web and Business Logic: 2.5 56 | View Layer: 3 57 | -------------------------------------------------------------------------------- /1407/01_mastermind/mastermind_submissions.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | Jim Sutton: 3 | repository: https://github.com/a6ftcruton/mastermind.git 4 | notes: "" 5 | evaluation: 6 | Fundamental Ruby & Style: 3 7 | Enumerable & Collections: 2.5 8 | Test-Driven Development: 2 9 | REPL Interface: 4 10 | Breaking Logic into Components: 3 11 | Kavita Sachdeva: 12 | repository: https://github.com/kavitasa/mastermind 13 | notes: "" 14 | evaluation: 15 | Fundamental Ruby & Style: 3- 16 | Enumerable & Collections: 2 17 | Test-Driven Development: 2- 18 | REPL Interface: 3 19 | Breaking Logic into Components: 2.5 20 | Glen Egbert: 21 | repository: 22 | notes: "" 23 | evaluation: 24 | Fundamental Ruby & Style: 3.5 25 | Enumerable & Collections: 3.5 26 | Test-Driven Development: 4 27 | REPL Interface: 3.5 28 | Breaking Logic into Components: 3 29 | Rolando Navarette: 30 | repository: https://github.com/rNavarrete/mastermind 31 | notes: "" 32 | evaluation: 33 | Fundamental Ruby & Style: 2.5 34 | Enumerable & Collections: 4 35 | Test-Driven Development: 2.5 36 | REPL Interface: 3.5 37 | Breaking Logic into Components: 3 38 | Sara Simon: 39 | repository: 40 | notes: "brainstormed things to test" 41 | evaluation: 42 | Fundamental Ruby & Style: 2.5 43 | Enumerable & Collections: 2 44 | Test-Driven Development: 2 45 | REPL Interface: 3 46 | Breaking Logic into Components: 1.5 47 | Luke Aiken: 48 | repository: git@github.com:lukeaiken/battleship.git 49 | notes: "" 50 | evaluation: 51 | Fundamental Ruby & Style: 1 52 | Enumerable & Collections: 4 53 | Test-Driven Development: 2 54 | REPL Interface: 1 55 | Breaking Logic into Components: 4 56 | Jessica Goulding: 57 | repository: git@github.com:JessicaG/battleship.git 58 | notes: "" 59 | evaluation: 60 | Fundamental Ruby & Style: 1 61 | Enumerable & Collections: 2 62 | Test-Driven Development: 1.5 63 | REPL Interface: 1 64 | Breaking Logic into Components: 2.5 65 | Cara Dennis: 66 | repository: git@github.com:objectParadigm/master-octo-mind-wallhack.git 67 | notes: "Pretty clean, nice code but the app did not work. Very polished REPL but it is not fully working." 68 | evaluation: 69 | Fundamental Ruby & Style: 2 70 | Enumerable & Collections: 3 71 | Test-Driven Development: 3 72 | REPL Interface: 2 73 | Breaking Logic into Components: 4 74 | Ian Anderson: 75 | repository: git@github.com:ianderse/battleship.git 76 | git@github.com:ianderse/mastermind.git 77 | notes: "Did two projects. Mastermind and Battleship. Both are working and are complete. Good level of effort." 78 | evaluation: 79 | Fundamental Ruby & Style: 2 80 | Enumerable & Collections: 3 81 | Test-Driven Development: 3 82 | REPL Interface: 3 83 | Breaking Logic into Components: 4 84 | Aaron Paul Wortham: 85 | repository: 86 | notes: "" 87 | evaluation: 88 | Fundamental Ruby & Style: 3 89 | Enumerable & Collections: 3 90 | Test-Driven Development: 3 91 | REPL Interface: 3.5 92 | Breaking Logic into Components: 4 93 | -------------------------------------------------------------------------------- /archive/1406/05_dinner_dash/dinner_dash_submissions.yml: -------------------------------------------------------------------------------- 1 | # NOTE: You can verify that you haven't broken the format with 2 | # $ ruby -rpp -ryaml -e 'pp YAML.load File.read("1406/04_clone_wars/clone_wars_submissions.yml") 3 | submissions: 4 | Andrew Watkins, Jonmichael Chambers, Marc Garreau, Chad Brading: 5 | repository: https://github.com/marcgarreau/grubhub_v2 6 | setup_notes: "" 7 | instructor_evaluation: 8 | notes: | 9 | Evaluated by Josh 10 | can't log out ;p~~~~~~ 11 | users and accounts are the same thing 12 | nice use of presenters 13 | Good tests in general, tiny bit not covered, but not for a particularly good reason 14 | Can't log out, yo, sharing my cart with mah homies 15 | no link to category 16 | orders "all" counts current order 17 | rubric: 18 | Feature Completeness: 3 19 | Views: 4 20 | Controllers: 3 21 | Models: 4 22 | TDD: 4- 23 | Usability: 3 24 | Horacio Chavez, Corey Davis, Tan Doan, Hilary Denton: 25 | repository: 26 | setup_notes: "" 27 | instructor_evaluation: 28 | notes: | 29 | Evaluated by Josh 30 | Feature Completeness 31 | No link to my profile/orders 32 | can see other people's orders 33 | cart is gone forever when I logout :( 34 | Can't edit user info 35 | admin orders missing total 36 | some links to transition that aren't actually available 37 | no Heroku :P 38 | Views 39 | use state machine instead of logic in admin orders view 40 | the logic that was there was wrong 41 | correctly indent the code 42 | find balance between the pristine pages (menu, front page) and the rest 43 | Controllers 44 | lots of dead code 45 | unnecessary json stuff 46 | session helper is better in application controller 47 | need to push knowledge of things like `role == 'admin'` down 48 | Models 49 | TDD 50 | high coverage, if you delete dead code :) 51 | things tested at feature level that would be better at a more focused level 52 | (e.g. I don't want to deal with the internet just to test how long a password can be) 53 | Usability 54 | most of the reasons are documented under features 55 | Unused routes 56 | most pages need aesthetic work 57 | the map doesn't show 58 | rubric: 59 | Feature Completeness: 1.5 60 | Views: 3 61 | Controllers: 3 62 | Models: 3.5 63 | TDD: 3 64 | Usability: 2 65 | Emily Davis, Tim Proctor, Gustavo Villagrana, Robert Gu: 66 | repository: git@github.com:BobGu/dinner_dash.git 67 | setup_notes: "" 68 | instructor_evaluation: 69 | notes: "" 70 | rubric: 71 | Feature Completeness: 1 72 | Views: 3 73 | Controllers: 3.5 74 | Models: 4 75 | TDD: 2.5 76 | Usability: 1.5 77 | Allison Larson, Andy Mention, Alan Smith, Will Faurot, Eric Fransen: 78 | repository: git@github.com:ericfransen/dinner_dash.git 79 | setup_notes: "" 80 | instructor_evaluation: 81 | notes: "" 82 | rubric: 83 | Feature Completeness: 2.5 84 | Views: 3 85 | Controllers: 3 86 | Models: 4 87 | TDD: 4 88 | Usability: 4 89 | -------------------------------------------------------------------------------- /archive/gschool-0/reading/eloquent_ruby/rg2/group_2_notes.markdown: -------------------------------------------------------------------------------- 1 | ## RG2 Notes for Eloquent Ruby 2 | 3 | ### Short Methods (CH10) & Operators (CH11) & Equality (CH12) 4 | 5 | #### Key Ideas 6 | 7 | + Rather than having a class with a few very large methods, have a class with many succinct, readable methods 8 | 9 | + That standard operators such as + and = are actually methods, and that you can alter their functionality. 10 | 11 | #### The Highlight 12 | 13 | It's useful to know how to write short methods and be able to re-define operators if needed. 14 | 15 | #### The Lowlight 16 | 17 | We are still nervous about overwriting the standard definitions of equalities and standard operators. We all felt that we'd feel more comfortable finding ways to express our code differently so that we don't need change them. None of us felt very comfortable in our understanding of _when_ it would be a great idea to re-define operators and equalities. 18 | 19 | ### Singletons (CH13) & Class Instance Variables (CH14) 20 | 21 | #### Key Ideas 22 | 23 | +You can build singleton methods "on the fly" to make your overall methods cleaner. For instance, when we built SalesEngine, instead of needing `find_by_id`, `find_by_name`, etc, you could create a `find_by` method that accepts the variable for searching when you need it. 24 | 25 | +Class Instance Variables should be used with caution -- there is probably a better way to do things. 26 | 27 | #### The Highlight 28 | 29 | Using singleton methods for metaprogramming was pretty cool! Most of us tried to use Class Instance variables in our SalesEngine project, and now we understand that it can be a dangerous thing to do. We also appreciated seeing how to rewrite code to stop using Class Instance variables. 30 | 31 | #### The Lowlight 32 | 33 | We're still not totally clear on the process of _how_ to write singleton methods effectively, and would have liked some more examples. 34 | 35 | ### Modules as Namespaces (CH15) & Mixins (CH16) 36 | 37 | #### Key Ideas 38 | 39 | + Modules can be used to group a related set of methods, like a class, but without instance/object creation. They're a *"class without state."* They also save you from namespacing clashes. 40 | 41 | + Mixins will let us store code for use in unrelated classes, as long as they're properly written. 42 | 43 | #### The Highlight 44 | 45 | Modules and mixins can store code to recall for multiple classes, saving you a lot of work. You can create instance or class methods, depending on whether you include or extend the module. 46 | 47 | #### The Lowlight 48 | 49 | We felt these two chapters were some of the clearest of the section, but we want to practice using modules and mixins a bit before really flying with them. 50 | 51 | ### Blocks (CH17) & Execute Around (CH18) & Execute Later (CH19) 52 | 53 | #### Key Ideas 54 | 55 | + The difference between block, proc, and lambda, and when to use them. 56 | + You can store a block for later use. 57 | 58 | #### The Highlight 59 | 60 | These chapters introduced us to concepts that we think will be incredibly useful with some practice, but we didn't feel confident with them after this reading. 61 | 62 | #### The Lowlight 63 | 64 | At first read, these chapters were the most confusing of the section. Olsen assumes you know what procs and lambdas are if you know what a block is. We don't fully understand when to use a proc _versus_ when to use a lambda. 65 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/denton_hilary.markdown: -------------------------------------------------------------------------------- 1 | # Walk About 2 | 3 | **SELECTED** 4 | 5 | #### Pitch 6 | 7 | An app that generates a walk starting from your current position that includes historical landmarks, murals, parks and other attractions. 8 | 9 | #### Description 10 | 11 | What it'll do: 12 | - The User will choose a distance and the types of things they would like to see, e.g. Murals, Historical Landmarks, Public works of art. 13 | - The App will then generate a walk that will include as many of those locations as possible in the distance the User has provided. 14 | - It will integrate with google maps or the maps app on iphone or whatever to give directions to the user via audio if they choose. 15 | - There could be some gameification involved, e.g. a badge for every city, a badge for various numbers of landmarks sited, a badge for number of completed walks. 16 | 17 | Why it should exist: 18 | - It should exist because people should be able to get to know their own city and neighborhood and become exposed to history, art etc.(for free) that they may not have noticed before 19 | - This is also made with tourists in mind. Say I have an hour before I see a show. It's not enough time to really go and do anything. With this app they could take a walk and see landmarks close to wherever they are.] 20 | 21 | #### Target Audience 22 | 23 | The target application would be tourists and those who live in the city and want to find out more. 24 | 25 | #### Integrations 26 | 27 | * OAuth: Google, 28 | Fitbit, 29 | DailyMile, 30 | RunKeeper 31 | 32 | * Data: City and County of Denver: Public Art, 33 | City and County of Denver: Historic Landmark Districts, 34 | City and County of Denver: Historic Landmarks, 35 | City and County of Denver: Downtown Denver Historic District, 36 | City and County of Denver: Lakes, 37 | City and County of Denver: Park Fountains, 38 | City and County of Denver: Parks 39 | 40 | * Integrations: Google Maps, 41 | Apple Maps App 42 | 43 | # Two 44 | 45 | ### [Street Sweep Notifier] 46 | 47 | 48 | #### Pitch 49 | 50 | An app that notifies you when the street sweeping is near you. 51 | 52 | #### Description 53 | 54 | You could put in where you are parked and it will notify you when there will be street sweeping there. 55 | Integrate SMS, you could maybe text the number your spot when you park there. 56 | 57 | #### Target Audience 58 | 59 | People who live in the city near street sweeping 60 | 61 | #### Integrations 62 | 63 | * What OAuth provider makes sense for this audience? Google 64 | * What Data.gov data or API will you use? City and County of Denver: Street Sweep Schedule 65 | * Any other integrations? Google maps? 66 | 67 | # Three 68 | 69 | ### [What Am I Eating?] 70 | 71 | 72 | #### Pitch 73 | 74 | Input a recipe get the nutrition facts 75 | #### Description 76 | 77 | Put in a recipe get an estimate of the amount of calories, grams of protein, fat etc. 78 | 79 | #### Target Audience 80 | 81 | People who want to know the nutritional content of their food without calculating each item one by one 82 | 83 | #### Integrations 84 | 85 | * What OAuth provider makes sense for this audience? Nest, some kind of food app(couldn't find one but i don't know what half of those appas are) 86 | * What Data.gov data or API will you use? Food Raw Data 87 | * Any other integrations? 88 | -------------------------------------------------------------------------------- /archive/gschool-0/reading/eloquent_ruby/rg2/group_5_notes.markdown: -------------------------------------------------------------------------------- 1 | ## RG2 Notes for Eloquent Ruby 2 | 3 | ### Short Methods (CH10) & Operators (CH11) & Equality (CH12) 4 | 5 | #### Key Ideas 6 | 7 | Keep your methods short & focused, be careful with custom operators. 8 | 9 | There are different forms of equality within Ruby, each serving a specific purpose. Messing around with operator methods 10 | can cause bugs in the code if we are not careful. 11 | 12 | #### The Highlight 13 | 14 | The biggest "OH" moment dealt with the comparisons of different forms of equality. We had covered a lot of the other topics in class, so this was one that we hadn't seen before. 15 | 16 | It will save us time to make good names for our methods and to write short methods that are targeted. During projects, this keep everything concise. 17 | 18 | #### The Lowlight 19 | 20 | The operator definitions seem like something that we won't touch until we become more comfortable with Ruby, in fear that 21 | we might screw something up. 22 | 23 | ### Singletons (CH13) & Class Instance Variables (CH14) 24 | 25 | #### Key Ideas 26 | 27 | Singletons are methods that apply to only one instance of a class. 28 | 29 | Don't use class variables unless you absolutely have to. Class instance variables are more appropriate for everyday use and will solve most of our problems. 30 | 31 | #### The Highlight 32 | 33 | Class methods are singleton methods, which now makes more sense after reading the section on Singleton methods. 34 | 35 | #### The Lowlight 36 | 37 | It was confusing when the author started talking about class instance varialbes and inheritance. In the example, the following code was used: 38 | 39 | class << self 40 | attr_accessor :default_font 41 | end 42 | 43 | We couldn't figure out exactly why this was necessary in order to set the default font for a subclass. 44 | 45 | ### Modules as Namespaces (CH15) & Mixins (CH16) 46 | 47 | #### Key Ideas 48 | 49 | Modules as namespaces can serve as a "last name" for identifying modules and avoiding confusion between similarly named classes. We can use it to share functionality between classes. 50 | 51 | #### The Highlight 52 | 53 | Modules are objects that can be used in a lot of different ways. It's great how flexible they are in comparison to classes. After thinking about how we approached SalesEngine, modules seem like a great way to save some time if we were to redo the project. 54 | 55 | #### The Lowlight 56 | 57 | This was one of the more exciting sections of the reading that helped us learn more about organization & namespacing. 58 | 59 | ### Blocks (CH17) & Execute Around (CH18) & Execute Later (CH19) 60 | 61 | #### Key Ideas 62 | 63 | Blocks are useful and powerful for iterating through code -- if you know how to use them. They can make a project much less noisy by accomplishing a lot within a small amount of code. 64 | 65 | #### The Highlight 66 | 67 | Getting a written perspective on blocks helped enforce the understanding of blocks and how iterators are used. Sometimes defining the iterator is confusing during actual coding, so this helped to break down those ideas. 68 | 69 | #### The Lowlight 70 | 71 | At this point, some of the ideas in these chapters proved to be confusing. It almost feels as though there are solutions that we aleady know which are less confusing to use -- that we feel more comfortable with. 72 | 73 | Some of the memory management pieces are a bit beyond our scope but we can at least keep them in mind while we make decisions. 74 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/brading_chad.markdown: -------------------------------------------------------------------------------- 1 | ### Time Tracker 2 | 3 | SELECTED 4 | 5 | #### Pitch 6 | 7 | Daily scheduling app that lets you share your schedule with your 8 | friends and view their schedules. 9 | 10 | #### Description 11 | 12 | Plan out your daily activities on a weekly planner. Choose which of your friends 13 | you would like to share your schedule with, and get invited by your friends to 14 | see their schedules as well. Upload photos and descriptions for events you went 15 | to with friends so you can remember those moments. Send reminders or messages to 16 | friends about upcoming events to build excitement. Use local weather forecasts to 17 | help you make your schedule. At the end of each week receive a retrospective 18 | email recapping your week. It could also prompt each user to submit a personal 19 | summary of their week, store these entries and show the previous entry to the 20 | user at the end of the week. 21 | 22 | 23 | #### Target Audience 24 | 25 | The target audience would range from young to old adults. The uses would vary 26 | for each demographic but each could customize it to their lifestyle. 27 | 28 | #### Integrations 29 | 30 | Facebook would make sense as an OAuth provider, as it would incorporate a daily 31 | planner/scheduling component into their features. Google would also make sense 32 | as it would expand on the capabilities of Google Calendar. 33 | 34 | It would use data from Weather Underground to provide users with information 35 | about their local weather. 36 | 37 | 38 | ### Deep Space Exploration 39 | 40 | #### Pitch 41 | 42 | An interactive astronomy game for people interested in learning more about outer 43 | space. 44 | 45 | #### Description 46 | 47 | The game would use images from planets, stars and other cosmic events to teach 48 | users to recognize the difference between each of these objects. It could be 49 | played using a memory style format, where images flash on the screen with their 50 | name, and then the names disappear and the user must recall what each image is. 51 | Other formats could be implemented where you have groups of categories, and the 52 | user must identify what each group of objects is or has in common. 53 | 54 | #### Target Audience 55 | 56 | Young people in school or anyone who wants to learn more about astronomy would 57 | be the target audience. 58 | 59 | #### Integrations 60 | 61 | Khan Academy or Coursera would make sense as an OAuth provider since it is an educational 62 | game. Perhaps Google could be an alternative because of its popularity. 63 | 64 | It would use images from NASA to create the content of the game. 65 | 66 | 67 | ### Airline Reviewer 68 | 69 | #### Pitch 70 | 71 | Airline review app that compares airlines based on number of flights delayed, 72 | reasons for delay and average difference between takeoff and scheduled departure 73 | time. 74 | 75 | #### Description 76 | 77 | The app would allow users to search by airline to get information on the 78 | percentage of their flights that are delayed, what caused the delay and how late 79 | the average flight was. They could choose two or more airlines to compare to see 80 | how their statistics relate. 81 | 82 | #### Target Audience 83 | 84 | The target audience would be anyone that flies regularly or is trying to choose 85 | an airline to fly with. 86 | 87 | #### Integrations 88 | 89 | Amazon or Google could be used as potential OAuth providers. 90 | 91 | Airline On-Time Statistics and Delay Causes from the Research and Innovative 92 | Technology Administration would be used to get data for the airline information. 93 | -------------------------------------------------------------------------------- /1407/02_event_reporter/event_reporter_submissions.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | Jim Sutton and Sara Simon: 3 | repository: https://github.com/a6ftcruton/event_reporter.git 4 | notes: "Tests present, but minimally functional. 5 | TDD strong at beginning of project, but tests didn't work after last-minute changes were made. 6 | Missing some functionality (print by and correctly-formatted CSV)." 7 | evaluation: 8 | Functional Expectations: 2 9 | REPL Interface: 3 10 | Test-Driven Development: 2 11 | Breaking Logic into Components: 3.5 12 | Fundamental Ruby & Style: 2.5 13 | Enumerable & Collections: 3.5 14 | Kavita Sachdeva and Ian Andersen: 15 | repository: git@github.com:ianderse/event_reporter.git 16 | notes: "Most example stories work well. 17 | Initially got rejected trying to save the file. 18 | One crash in the emptiness story. 19 | Testing and decomposition are well done. 20 | Code shows good effort towards readability. 21 | " 22 | evaluation: 23 | Functional Expectations: 2 24 | REPL Interface: 3 25 | Test-Driven Development: 3 26 | Breaking Logic into Components: 4 27 | Fundamental Ruby & Style: 3 28 | Enumerable & Collections: 3 29 | Luke Aiken and Glen Egbert: 30 | repository: Luke: https://github.com/lukeaiken/event_reporter, Glen: https://github.com/glenegbert/mastermind.git 31 | notes: "Some test cases execute properly. 32 | Good implementation of fundamental finding, printing. 33 | Doesn't handle some edge cases. 34 | Tests don't run, needs better coverage. 35 | Decomposition is good. 36 | Ruby is overall strong, but tries to do too much in places. 37 | Good use of enumerable methods." 38 | evaluation: 39 | Functional Expectations: 1 40 | REPL Interface: 3 41 | Test-Driven Development: 1.5 42 | Breaking Logic into Components: 3 43 | Fundamental Ruby & Style: 3 44 | Enumerable & Collections: 3 45 | Jessica Goulding and Rolando Navarette: 46 | repository:https://github.com/JessicaG/event_reporter_rj 47 | notes: "Crashes during find w/o load and reloading CSV. 48 | Good use of best-choice enumerables. 49 | Decent separation of logic -- confusion with CLI and UserCommand class. 50 | For Fundamental Ruby & Style -- looks mostly good, but app crashes because errors are not handled." 51 | evaluation: 52 | Functional Expectations: 2 53 | REPL Interface: 4 54 | Test-Driven Development: 3 55 | Breaking Logic into Components: 3 56 | Fundamental Ruby & Style: 2 57 | Enumerable & Collections: 4 58 | Cara Dennis and Aaron Paul Wortham: 59 | repository: git@github.com:objectParadigm/event-reporter.git 60 | notes: "Some small deviations from the spec instructions. 61 | Save outputs good data but misses headers, so re-load won't work. 62 | Emptiness story won't work because data is autoloaded. 63 | Bummer that some tests/code got lost up git creek. 64 | Good Ruby structures and style. 65 | Watch out for little debugging bits lingering around. 66 | Ruby shows good style and care. 67 | Good use of several enumerable techniques." 68 | evaluation: 69 | Functional Expectations: 2 70 | REPL Interface: 3 71 | Test-Driven Development: 2 72 | Breaking Logic into Components: 3 73 | Fundamental Ruby & Style: 3 74 | Enumerable & Collections: 3 75 | -------------------------------------------------------------------------------- /1407/04_clone_wars/clone_wars_submissions.yml: -------------------------------------------------------------------------------- 1 | # NOTE: You can verify that you haven't broken the format with 2 | # $ ruby -rpp -ryaml -e 'pp YAML.load File.read("1406/04_clone_wars/clone_wars_submissions.yml") 3 | submissions: 4 | "Cara Dennis & Jim Sutton & Kavita Sachdeva & Rolando Navarrete": 5 | repository: "git@github.com:objectParadigm/jimmys-urban-bar-and-grill.git" 6 | setup_notes: "" 7 | instructor_evaluation: 8 | notes: "all base expectations fulfilled; added one interactive element. 9 | admin menu able to be edited w/o being logged in as administrator. 10 | some acceptance tests (creating user, creating menu items), but unit tests missing. 11 | used all http verbs; some mixing of web & business logic. 12 | views used layouts and partials to avoid code replication. 13 | many concerns about order of lessons and lack of important concepts in lessons." 14 | rubric: 15 | Functional Expectations: 3 16 | Test-Driven Development: 2 17 | Encapsulation / Components: 2.5 18 | Fundamental Ruby & Style: 2.5 19 | Sinatra / Web and Business Logic: 3 20 | View Layer: 3.5 21 | "Sara Simon & Ian Andersen & Glen Egbert": 22 | repository: "git@github.com:ianderse/clone_wars.git" 23 | setup_notes: "" 24 | instructor_evaluation: 25 | notes: "recreated original site; added banner, contact, reservation, and reviews. 26 | admin able to edit items (name, size, price, image). 27 | saw good testing at feature level; would like to see more things tested in isolation. 28 | good divisions of logic and encapsulation; content store probably could have been broken into a repository and a seracher. 29 | easy to read and follow code. 30 | saw use of layout and partials to avoid code duplication; did not see use of helpers. 31 | " 32 | rubric: 33 | Functional Expectations: 4 34 | Test-Driven Development: 2 35 | Encapsulation / Components: 3.5 36 | Fundamental Ruby & Style: 4 37 | Sinatra / Web and Business Logic: 3.5 38 | View Layer: 3.5 39 | "Jessica Goulding & Luke Aiken & Aaron Paul Wortham": 40 | repository: "https://github.com/JessicaG/slice_works_clone" 41 | setup_notes: "" 42 | instructor_evaluation: 43 | notes: "several routes that do not work (missing template, error pages). 44 | content on pages well-tested; missing tests for user authentication and ability to edit. 45 | started classes for menu and menu item, but not implemented. 46 | would like to see controller not as responsible for executing DB commands and raw sql. 47 | app crashed during execution, but code showed effort toward organization and refactoring. 48 | web and business logic mixed, but used features of Sinatra (Rack::Session, setting variables based on ENV); used helpers to authenticate user 49 | views contain minimal logic; make use of layout and partials; did not see built-in view helpers. 50 | " 51 | rubric: 52 | Functional Expectations: 1 53 | Test-Driven Development: 2.5 54 | Encapsulation / Components: 2 55 | Fundamental Ruby & Style: 1.5 56 | Sinatra / Web and Business Logic: 2.5 57 | View Layer: 3.5 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 | 71 | 72 | 73 | 74 | 75 | 76 | -------------------------------------------------------------------------------- /archive/1406/02_event_reporter/event_reporter_submissions.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | Corey Davis & Emily Davis: 3 | repository: git@github.com:coreyd303/eventreporter_davis_davis.git 4 | notes: "You will need the following gems to successfully run our program: colorize, terminal-table, ValidateEmail" 5 | evaluation: 6 | Functional Expectations: 3 7 | REPL Interface: 3.5 8 | Test-Driven Development: 1.5 9 | Breaking Logic into Components: 3 10 | Fundamental Ruby & Style: 2 11 | Enumerable & Collections: 3 12 | Chad Brading & Robert Gu: 13 | repository: git@github.com:chadbrading/event_reporter.git 14 | notes: "" 15 | evaluation: 16 | Functional Expectations: 4 17 | REPL Interface: 2 18 | Test-Driven Development: 3 19 | Breaking Logic into Components: 3 20 | Fundamental Ruby & Style: 2.5 21 | Enumerable & Collections: 3 22 | Jonmichael Chambers & Alan Smith: 23 | repository: https://github.com/alanbsmith/EventReporter 24 | notes: "Added Queue Math. Improved Queue Print. Improved Find. Partial support for Nightmare mode Find. Some other improvements (imo)." 25 | evaluation: 26 | Functional Expectations: 4 27 | REPL Interface: 3.5 28 | Test-Driven Development: 4 29 | Breaking Logic into Components: 4 30 | Fundamental Ruby & Style: 4 31 | Enumerable & Collections: 4 32 | Allison Larson & Tim Proctor: 33 | repository: https://github.com/timproctor/event-reporter 34 | notes: 35 | evaluation: 36 | Functional Expectations: 3 37 | REPL Interface: 3.5 38 | Test-Driven Development: 3 39 | Breaking Logic into Components: 3 40 | Fundamental Ruby & Style: 2 41 | Enumerable & Collections: 3 42 | Will Faurot & Hilary Denton: 43 | repository: git@github.com:Hilaryous/event_reporter.git 44 | notes: "implemented save_to extension for only csv and txt files" 45 | evaluation: 46 | Functional Expectations: 3 47 | REPL Interface: 3 48 | Test-Driven Development: 3 49 | Breaking Logic into Components: 3 50 | Fundamental Ruby & Style: 2.5 51 | Enumerable & Collections: 3 52 | Cara Dennis & Gustavo Villagrana: 53 | repository: git@github.com:objectParadigm/event-cloaked-wallhack-reporter.git 54 | notes: "" 55 | evaluation: 56 | Functional Expectations: 3 57 | REPL Interface: 3 58 | Test-Driven Development: 2 59 | Breaking Logic into Components: 2 60 | Fundamental Ruby & Style: 3 61 | Enumerable & Collections: 3 62 | Notes: 63 | Help rolls individual queue items into one 64 | Queue print only sorts by last_name 65 | Tests not passing 66 | Jessica Goulding & Eric Fransen: 67 | repository: https://github.com/JessicaG/event_reporter 68 | notes: "Gems needed are terminal-table and colorize" 69 | evaluation: 70 | Functional Expectations: 1 71 | REPL Interface: 3 72 | Test-Driven Development: 1 73 | Breaking Logic into Components: 2 74 | Fundamental Ruby & Style: 2 75 | Enumerable & Collections: 3 76 | Notes: 77 | Help misses the individual help items 78 | Needs output folder to be made by hand 79 | Extra .csv on output files 80 | Failed story D & E 81 | Tests do not run 82 | Andrew Watkins & Horacio Chavez: 83 | repository: git@github.com:121watts/event-reporter.git 84 | notes: "no need for underscores in search fields i.e. first_name is simply first name" 85 | evaluation: 86 | Functional Expectations: 2 87 | REPL Interface: 3.1 88 | Test-Driven Development: 3 89 | Breaking Logic into Components: 3 90 | Fundamental Ruby & Style: 3 91 | Enumerable & Collections: 3.1 92 | Notes: 93 | Queue print by only uses last name 94 | Queue does not output CSV 95 | Loads up the data at startup without Load 96 | Tan Doan & Andy Mention & Marc Garreau: 97 | repository: git@github.com:MarcGarreau/turing_event_reporter.git 98 | notes: "" 99 | evaluation: 100 | Functional Expectations: 3 101 | REPL Interface: 3 102 | Test-Driven Development: 2 103 | Breaking Logic into Components: 2 104 | Fundamental Ruby & Style: 3 105 | Enumerable & Collections: 3 106 | Notes: 107 | All stories passed with one little fix 108 | Tests do not run as-is because of missing data file 109 | Tests not deep enough, broad enough, need more levels of abstraction 110 | -------------------------------------------------------------------------------- /1409/03_sales_engine/sales_engine_submissions.yml: -------------------------------------------------------------------------------- 1 | Chandra Carney & Gregory Narajka: 2 | repository: https://github.com/gregnar/sales_engine.git 3 | setup_notes: "" 4 | instructor_evaluation: 5 | notes: "fulfills all base expectations. 6 | passes spec harness. 7 | well-tested; would like to see unit tests and integration tests split apart. 8 | application shows strong effort towards organization, content, and refactoring. 9 | application consistently makes use of the best-choice Enumerable methods." 10 | rubric: 11 | Functional Expectations: 3 12 | Test-Driven Development: 3 13 | Encapsulation / Components: 3.5 14 | Fundamental Ruby & Style: 3 15 | Enumerable & Collections: 4 16 | Code Sanitation: 4 17 | 18 | Sam Kuhlmann & Zachary Routhier: 19 | repository: https://github.com/skuhlmann/sales_engine 20 | setup_notes: "" 21 | instructor_evaluation: 22 | notes: "Application fulfills all base expectations as tested by the spec harness. 23 | Application is well tested but does not balance isolation and integration tests, using only the data necessary to test the functionality. 24 | Application effectively breaks logical components apart but breaks the principle of SRP. 25 | Application shows strong effort towards organization, content, and refactoring. 26 | Application consistently makes use of the best-choice Enumerable methods." 27 | rubric: 28 | Functional Expectations: 3 29 | Test-Driven Development: 3.5 30 | Encapsulation / Components: 3 31 | Fundamental Ruby & Style: 3.5 32 | Enumerable & Collections: 4 33 | Code Sanitation: 3 34 | 35 | Travis Yoder & David Bayendor: 36 | repository: git@github.com:trayo/sales_engine.git 37 | setup_notes: "" 38 | instructor_evaluation: 39 | notes: "Well-tested in isolation and w/ mocks for repos and sales engine. Would like to see tests for sales engine logic. 40 | All but three tests passing in spec harness. 41 | Application shows strong effort towards organization, content, and refactoring. 42 | Application consistently makes use of the best-choice Enumerable methods. 43 | Zero complaints for rake sanitation." 44 | rubric: 45 | Functional Expectations: 2.5 46 | Test-Driven Development: 3 47 | Encapsulation / Components: 3 48 | Fundamental Ruby & Style: 3 49 | Enumerable & Collections: 4 50 | Code Sanitation: 4 51 | 52 | Adam Smith & Alex Jensen & Herbert Joseph: 53 | repository: 54 | setup_notes: "" 55 | instructor_evaluation: 56 | notes: "" 57 | rubric: 58 | Functional Expectations: 59 | Test-Driven Development: 60 | Encapsulation / Components: 61 | Fundamental Ruby & Style: 62 | Enumerable & Collections: 63 | Code Sanitation: 64 | 65 | Chase van Hekken & Christopher Bynum: 66 | repository: 67 | setup_notes: "" 68 | instructor_evaluation: 69 | notes: "" 70 | rubric: 71 | Functional Expectations: 72 | Test-Driven Development: 73 | Encapsulation / Components: 74 | Fundamental Ruby & Style: 75 | Enumerable & Collections: 76 | Code Sanitation: 77 | 78 | Danny Glunz & Victoria Harrod: 79 | repository: https://github.com/dglunz/sales_engine.git 80 | setup_notes: "" 81 | instructor_evaluation: 82 | notes: "" 83 | rubric: 84 | Functional Expectations: 85 | Test-Driven Development: 86 | Encapsulation / Components: 87 | Fundamental Ruby & Style: 88 | Enumerable & Collections: 89 | Code Sanitation: 90 | 91 | Kalah Cheek & Konr Josef Larson: 92 | repository: https://github.com/larsonkonr/sales_engine.git 93 | setup_notes: "" 94 | instructor_evaluation: 95 | notes: "" 96 | rubric: 97 | Functional Expectations: 98 | Test-Driven Development: 99 | Encapsulation / Components: 100 | Fundamental Ruby & Style: 101 | Enumerable & Collections: 102 | Code Sanitation: 103 | 104 | Kate Lane & Timothy Mee: 105 | repository: git@github.com:Tmee/sales_engine_project.git 106 | setup_notes: "" 107 | instructor_evaluation: 108 | notes: "" 109 | rubric: 110 | Functional Expectations: 111 | Test-Driven Development: 112 | Encapsulation / Components: 113 | Fundamental Ruby & Style: 114 | Enumerable & Collections: 115 | Code Sanitation: 116 | 117 | -------------------------------------------------------------------------------- /archive/gschool-1/projects/services.rb: -------------------------------------------------------------------------------- 1 | def project 2 | { 3 | :group1 => { :project_name => 'FreshFinder', 4 | :members => ['Katrina Engelsted', 'Lauren Spath Luhring', 'Simon Taranto', 'Persa Zula'], 5 | :repo_url => 'https://github.com/FreshFinder', 6 | :tracker_url => 'https://www.pivotaltracker.com/s/projects/1002246', 7 | :staging_url => ' - ', 8 | :production_url => 'http://FreshFinder.us', 9 | :vps_owner_email => 'simon.taranto@gmail.com', 10 | :client_satisfaction => {}, 11 | :technical_evaluation => { 12 | :services => 3, 13 | :encapsulation => 3, 14 | :mvc => 4, 15 | :testing => 4, 16 | :comments => "Good wrapping, could pull the wrappers our to a gem. 17 | Great job breaking components down and pushing logic down the stack. 18 | Like how you approached testing." 19 | }, 20 | :learning_and_progress => {} 21 | }, 22 | :group2 => { :project_name => 'Community Playdates', 23 | :members => ['Antony Siegert', 'Ben Horne', 'Jonah Moses', 'Magan Adam'], 24 | :repo_url => 'https://github.com/JonahMoses/community_playdates', 25 | :tracker_url => 'https://www.pivotaltracker.com/s/projects/1002306', 26 | :staging_url => 'community-palydates.herokuapps.com',:project_name => '', 27 | :production_url => 'http://communityplaydates.com', 28 | :vps_owner_email => 'benhorne44@gamil.com', 29 | :client_satisfaction => {}, 30 | :technical_evaluation => { 31 | :services => 3, 32 | :encapsulation => 3, 33 | :mvc => 2.5, 34 | :testing => 1, 35 | :comments => "" 36 | }, 37 | :learning_and_progress => {} 38 | }, 39 | :group3 => { :project_name => 'Planting Season', 40 | :members => ['Tyler Long', 'Luke Martinez', 'Ben Lewis', 'Nathaniel Watts'], 41 | :repo_url => 'http://github.com/Virginsoil', 42 | :tracker_url => 'https://www.pivotaltracker.com/s/projects/1002278', 43 | :staging_url => '', 44 | :production_url => 'http://162.243.221.189/', 45 | :vps_owner_email => 'reg@thewatts.com', 46 | :client_satisfaction => {}, 47 | :technical_evaluation => { 48 | :services => 3.5, 49 | :encapsulation => 4, 50 | :mvc => 2.5, 51 | :testing => 1, 52 | :comments => "" 53 | }, 54 | :learning_and_progress => {} 55 | }, 56 | :group4 => { :project_name => 'Walk It Off', 57 | :members => [''], 58 | :repo_url => 'https://github.com/Egogre/project-x', 59 | :tracker_url => 'https://www.pivotaltracker.com/s/projects/1002332', 60 | :staging_url => '', 61 | :production_url => '', 62 | :vps_owner_email => '', 63 | :client_satisfaction => { 64 | }, 65 | :technical_evaluation => { 66 | :services => 2, 67 | :encapsulation => 3, 68 | :mvc => 3, 69 | :testing => 4, 70 | :comments => "Implemented one service as a middleware. 71 | Service access is effectively pushed down to one model. 72 | Great job pushing logic down the stack, view templates are complex." 73 | }, 74 | :learning_and_progress => {} 75 | }, 76 | :group5 => { :project_name => 'The Fridge', 77 | :members => ['Will Mitchell', 'Meeka Gayhart', 'Rolen Le', 'Billy Griffin'], 78 | :repo_url => 'https://github.com/TheFridge', 79 | :tracker_url => 'https://www.pivotaltracker.com/s/projects/1002288', 80 | :staging_url => 'http://recipemama.herokuapp.com', 81 | :production_url => 'http://thefridge.tk', 82 | :vps_owner_email => 'wvmitchell@gmail.com', 83 | :client_satisfaction => { 84 | :services => 3, 85 | :encapsulation => 3, 86 | :mvc => 3, 87 | :testing => 3, 88 | :comments => "" 89 | }, 90 | :technical_evaluation => {}, 91 | :learning_and_progress => {} 92 | } 93 | } 94 | end 95 | 96 | def config 97 | {:abbreviation => 'services'} 98 | end 99 | -------------------------------------------------------------------------------- /1410/02_event_reporter/event_reporter_submissions.yml: -------------------------------------------------------------------------------- 1 | submissions: 2 | Alexandra Robinson & Juan Manuel Navarro: 3 | repository: https://github.com/scottalexandra/event_reporter 4 | evaluation: 5 | notes: "Some base functionality; missing print by functionality. One crash when user entered invalid help command. 6 | REPL is easy to read, but missing some functionality. 7 | Good intent with TDD but tests were not updated as application grew and changed. 8 | Can see effort toward organization and refactoring. 9 | Good understanding of basic enums (collect, select, sort)." 10 | Functional Expectations: 2 11 | REPL Interface: 2.5 12 | Test-Driven Development: 2 13 | Breaking Logic into Components: 2.5 14 | Fundamental Ruby & Style: 3 15 | Enumerable & Collections: 3 16 | Andrew Overby & Chris Luhring: 17 | repository: https://github.com/cluhring/event_reporter 18 | evaluation: 19 | notes: git issues, flustered, possibly discouraged 20 | Functional Expectations: 1 21 | REPL Interface: 1 22 | Test-Driven Development: 2 23 | Breaking Logic into Components: 2.5 24 | Fundamental Ruby & Style: 2.5 25 | Enumerable & Collections: 2.5 26 | Kit Pearson & Orion Osborn: 27 | repository: https://github.com/oorion/event_reporter 28 | evaluation: 29 | notes: "" 30 | Functional Expectations: 2 31 | REPL Interface: 3 32 | Test-Driven Development: 2 33 | Breaking Logic into Components: 2.5 34 | Fundamental Ruby & Style: 3 35 | Enumerable & Collections: 3 36 | Brandon Mrsny & Nathan Owsiany: 37 | repository: https://github.com/bmrsny/event_reporter 38 | evaluation: 39 | notes: "" 40 | Functional Expectations: 4 41 | REPL Interface: 4 42 | Test-Driven Development: 4 43 | Breaking Logic into Components: 4 44 | Fundamental Ruby & Style: 3 45 | Enumerable & Collections: 4 46 | Dustin Gault & Emily Berkeley: 47 | repository: https://github.com/DSynergy/Event_Reporter 48 | evaluation: 49 | notes: "" 50 | Functional Expectations: 3.5 51 | REPL Interface: 4 52 | Test-Driven Development: 3 53 | Breaking Logic into Components: 3 54 | Fundamental Ruby & Style: 2.5 55 | Enumerable & Collections: 4 56 | Lori Culberson & Michael Dao: 57 | repository: https://github.com/mikedao/event_reporter 58 | evaluation: 59 | notes: "Application fulfills all base expectations. 60 | REPL clear to use -- possibly would have been nice to have a message to user when input cannot be processed instead of another >. 61 | Watch for where 'puts' is being called. 62 | " 63 | Functional Expectations: 3 64 | REPL Interface: 3 65 | Test-Driven Development: 3.5 66 | Breaking Logic into Components: 3 67 | Fundamental Ruby & Style: 3 68 | Enumerable & Collections: 3 69 | Bhargavi Satpathy & Jeffrey Wan & Edward McCarthy: 70 | repository: https://github.com/bhargavisatpathy/event_manager 71 | evaluation: 72 | notes: "One problem loading a generated file, but all other base expectations fulfilled and two extensions implemented. 73 | Break down 'Session' class further. 74 | " 75 | Functional Expectations: 3.5 76 | REPL Interface: 3 77 | Test-Driven Development: 3.5 78 | Breaking Logic into Components: 3 79 | Fundamental Ruby & Style: 3 80 | Enumerable & Collections: 3 81 | Bryce Holcomb & Laura Whalin: 82 | repository: https://github.com/bryceholcomb/event_reporter 83 | evaluation: 84 | notes: "All base expectations fulfilled; implemented 'and' searching (need to account for invalid user input on this feature). 85 | Test coverage is sufficient -- great testing of isolated pieces; also good testing of saving a csv and using mocks. 86 | Fairly well broken-down logic." 87 | Functional Expectations: 3 88 | REPL Interface: 3.5 89 | Test-Driven Development: 3 90 | Breaking Logic into Components: 3 91 | Fundamental Ruby & Style: 3 92 | Enumerable & Collections: 3 93 | Rich Shea & Scott Crawford: 94 | repository: https://github.com/scottcrawford03/event_reporter 95 | evaluation: 96 | notes: "All base expectations fulfilled; partially implemented two extensions. 97 | REPL is easy to use; tables are nicely formatted. 98 | Well-factored code; processor could use some refactoring." 99 | Functional Expectations: 3 100 | REPL Interface: 3.5 101 | Test-Driven Development: 3.5 102 | Breaking Logic into Components: 3 103 | Fundamental Ruby & Style: 3 104 | Enumerable & Collections: 3 105 | Lydia Shafer & Krista A Nelson: 106 | repository: https://github.com/KristaANelson/event_reporter 107 | evaluation: 108 | notes: "" 109 | Functional Expectations: 3 110 | REPL Interface: 4 111 | Test-Driven Development: 3.5 112 | Breaking Logic into Components: 3 113 | Fundamental Ruby & Style: 3 114 | Enumerable & Collections: 3 115 | -------------------------------------------------------------------------------- /archive/1406/07_self_directed_project/Gu_Robert.markdown: -------------------------------------------------------------------------------- 1 | ****SELECTED**** 2 | 3 | 4 | ####Umbrella#### 5 | 6 | A simple application that sends you a SMS notice that lets you know 7 | what type of clothes you might need to wear for the day. 8 | #### Description 9 | Based on the weather forcast for the rest of the day, this app will 10 | simply let you know if you need a jacket or umbrella for the day ahead! 11 | No need to check the weather anymore. People visiting the site can 12 | enter in a range for tempatures for needing a light jacket/sweater, or a 13 | heavier coat. Also they can specify at which percnetage change of 14 | percipation they get sent a text for rain. 15 | . 16 | #### Target Audience 17 | For those that don't keep a jacket and raincoat on them very often or are too 18 | lazy to check the weather. 19 | #### Integrations 20 | 21 | Facebook is used widely across a lot of people so might be most useful. 22 | It can also use remember the milk, since this is an app used as a task 23 | management tool, remembering to bring your jacket or raincoat seems like 24 | a task that people that use this tool want to automate. 25 | 26 | I would use weather undergroud as the API to help decide to 27 | use this app or not. 28 | 29 | Also I think using rember the milk API could be useful if people don't want 30 | to recieve texts daily, but have it create remind using RTM instead of getting 31 | daily texts. 32 | 33 | 34 | 35 | 36 | #### Idea 2 37 | #### Pitch 38 | Name that tune game, based on category two users compete to name the tune 39 | in a certain amount of seconds 40 | 41 | #### Description 42 | Based of the popular gameshow from the late 80's players compete to name that 43 | tune bidding back and forth and trying to fill in the answer correctly. 44 | 45 | #### Target Audience 46 | Any music lovers looking to have a little fun! 47 | 48 | #### Integrations 49 | 50 | 51 | Here I think the facebook OAuth makes the most sense. It is the most 52 | widely used I would assume across the people this tool is targeted towards. 53 | 54 | This would make use of the spotify API and also lyricsfiy API to gather 55 | information about the songtitle and artist. 56 | 57 | 58 | #### IDEA 3 59 | 60 | #### Pitch 61 | 62 | Homebuyer, shows you information about schools and level of crime around 63 | the house you are trying to buy. 64 | 65 | 66 | 67 | #### Description 68 | People can enter in a zipcode and see homes that are in that area. It will show 69 | homes that have the price, crime level around that area, and also how 70 | the schools are rated around that area as well. Other features would let you 71 | sort by price, bedrooms, crime, best schools. 72 | #### Target Audience 73 | Target audience in home buyers that are also concerned about schools in that 74 | area and also crime rates as well. 75 | #### Integrations 76 | I can use the public data available. Data SF has an API about a lot of their 77 | cities information, and crime data is public. I also thought about integration 78 | with zillows API that way you can find homes that are nearby your search area. 79 | 80 | I think I would use facebook gain for OAuth for this audience. 81 | 82 | 83 | #### Idea 4 84 | An application that looks for both a brewery and food truck, and based 85 | on combined yelp ratings gives you best place to get a beer and some food. 86 | 87 | #### Description 88 | Someone can search by zip, type of food, or type of beer, and filter the 89 | results of breweries and food trucks returned. By default it will 90 | return the best food truck brewery combo of the day. It will pictures 91 | of both the brewery and food truck loaded onto the page, and also easy 92 | to read menus for both places. 93 | 94 | #### Target Audience 95 | People looking for something to eat and drink after work. 96 | 97 | #### Integrations 98 | This will mainly use Yelps API but also use googlemaps to give location 99 | information as well. Also it will need to integrate twitter APIs so we 100 | can find the locations of those food trucks as well. 101 | 102 | 103 | #### Idea 5 104 | 105 | #### Pitch 106 | Based on what trail you pick and how many miles it is/difficult it is 107 | we pack the necessary amount of food for you. Too often people pack too 108 | much or too little when they go hiking. 109 | 110 | #### Description 111 | People can find a trail and using the trail.api data. This will 112 | plot the trail for them and give them an idea of how long the trail is 113 | recommended amount of time it takes to hike and will give them a list of food 114 | items that we will pack for them, so they have just the right amount of food. 115 | People can also list if they need stuff that is gluten free, and a special 116 | comment box for other food allergies. Email based portion will ask 117 | them if they prefer one item over another is their package of food. 118 | 119 | #### Target Audience 120 | Amateur or newbie hikers who are unsure of what to pack when they go on a hike. 121 | Also for the hardcore outdoor enthuisast that just love using our service 122 | since we work with the best healthy food providers. 123 | 124 | #### Integrations 125 | I would use facebooks API since it is the most widely used. 126 | 127 | I would use trail.api and if colorado had any open source info I would use 128 | them as well. Also I would make use of weather underground or some other 129 | service that way when a hiker puts in the dates of his hike I can give 130 | him a weather forcast as well! 131 | 132 | 133 | --------------------------------------------------------------------------------