tykurtz

GROKKING NOTES

I liked the way Grokking the coding interview organized problems into learnable patterns. However, the course is expensive and the majority of the time the problems are copy-pasted from leetcode. As the explanations on leetcode are usually just as good, the course really boils down to being a glorified curated list of leetcode problems.

So below I made a list of leetcode problems that are as close to grokking problems as possible.

Pattern: Sliding Window

• https://leetcode.com/problems/maximum-subarray/ # Close enough
• https://leetcode.com/problems/minimum-size-subarray-sum/

ksmithut

node_modules

heechul

'''
Based the following two code bases:
 - Berkeley's CS188 pacman project code
   http://ai.berkeley.edu/
 - Victor Mayoral Vilches's RL tutorial 
   https://github.com/vmayoral/basic_reinforcement_learning

@author: Heechul Yun (heechul.yun@gmail.com)
'''

chantastic

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't

domenic

Auto-deploying built products to gh-pages with GitHub Actions

This is a set up for projects which want to check in only their source files, but have their gh-pages branch automatically updated with some compiled output every time they push.

A file below this one contains the steps for doing this with Travis CI. However, these days I recommend GitHub Actions, for the following reasons:

• It is much easier and requires less steps, because you are already authenticated with GitHub, so you don't need to share secret keys across services like you do when coordinate Travis CI and GitHub.
• It is free, with no quotas.
• Anecdotally, builds are much faster with GitHub Actions than with Travis CI, especially in terms of time spent waiting for a builder.

staltz

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

---

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

---

Chaser324

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j

macintux

• https://dancres.github.io/Pages/
• https://ferd.ca/a-distributed-systems-reading-list.html
• http://the-paper-trail.org/blog/distributed-systems-theory-for-the-distributed-systems-engineer/
• https://github.com/palvaro/CMPS290S-Winter16/blob/master/readings.md
• http://muratbuffalo.blogspot.com/2015/12/my-distributed-systems-seminars-reading.html
• http://christophermeiklejohn.com/distributed/systems/2013/07/12/readings-in-distributed-systems.html
• http://michaelrbernste.in/2013/11/06/distributed-systems-archaeology-works-cited.html
• http://rxin.github.io/db-readings/
• http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html
• http://pdos.csail.mit.edu/dsrg/papers/

ragingwind

Backend Architectures

Twitter

ror, scala, jetty, erlang, thrift, mongrel, comet server, my-sql, memchached, varnish, kestrel(mq), starling, gizzard, cassandra, hadoop, vertica, munin, nagios, awstats

• Introduce Gizzard of Twitter - 트위터의 새로운 분산 관리 라이브러리 Gizzard를 소개합니다.
• The Architecture Twitter Uses to Deal with 150M Active Users, 300K QPS, a 22 MB/S Firehose, and Send Tweets in Under 5 Seconds
• Scaling Twitter: Making Twitter 10000 Percent Faster

dypsilon

Backend Development

• node.js
  • Installation paths: use one of these techniques to install node and npm without having to sudo.
  • Node.js HOWTO: Install Node+NPM as user (not root) under Unix OSes
  • Felix's Node.js Guide
  • Creating a REST API using Node.js, Express, and MongoDB
  • Node Cellar Sample Application with Backbone.js, Twitter Bootstrap, Node.js, Express, and MongoDB
  • JavaScript Event Loop
• Node.js for PHP programmers