ESPN's hidden API endpoints
Latest News: http://site.api.espn.com/apis/site/v2/sports/football/college-football/news
Latest Scores: http://site.api.espn.com/apis/site/v2/sports/football/college-football/scoreboard
Python
tap "caskroom/cask" | |
cask "google-chrome" | |
cask "firefox" | |
brew "chromedriver" | |
brew "geckodriver" |
#pragma comment(lib, "SDL2") | |
#pragma comment(lib, "SDL2main") | |
#include "SDL.h" | |
#include <vector> | |
#include <unordered_map> | |
#include <assert.h> | |
#include <algorithm> |
begin | |
require "bundler/inline" | |
rescue LoadError => e | |
$stderr.puts "Bundler version 1.10 or later is required. Please update your Bundler" | |
raise e | |
end | |
gemfile(true) do | |
source "https://rubygems.org" |
// assume sequential consistency. | |
// this technique prevents frequent synchronization (cache line thrashing) of the read/write positions | |
// in the case where the ring buffer is running neither too close to full or too close to empty. it | |
// relies on the fact that an out of date notion of the read/write positions are conservative approximations. | |
// globals in shared memory. assume in different cache lines to prevent false sharing. | |
int read_pos, write_pos; | |
// reader |
This is the second entry in my series about API design. While I wrote about granularity and request based APIs in my last post I want to write about API design and code architecture for modular data-oriented process this time. This is basically the write up of my findings while writing and finishing the core of my current GUI research quarks.
Actually sparking my interest for writing up my findings however was rasmusbarr@github (rasmusbarr@twitter) releasing his small data-oriented and SIMD-optimized 3D rigid body physics library. I noticed a lot of overlap in design between his physics and my GUI library and wanted to write up some general thoughts about what seems
require 'thread' | |
mutex = Mutex.new | |
10000.times do |i| | |
r,w = IO.pipe | |
t = Thread.new { | |
begin | |
loop do |