onlurking

Programming as Theory Building

Peter Naur

Peter Naur's classic 1985 essay "Programming as Theory Building" argues that a program is not its source code. A program is a shared mental construct (he uses the word theory) that lives in the minds of the people who work on it. If you lose the people, you lose the program. The code is merely a written representation of the program, and it's lossy, so you can't reconstruct

timvisee

Falsehoods programmers believe about time

This is a compiled list of falsehoods programmers tend to believe about working with time.

Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.

Falsehoods

• There are always 24 hours in a day.
• February is always 28 days long.
• Any 24-hour period will always begin and end in the same day (or week, or month).

odewahn

I really liked @tjvantoll article Handling Failed HTTP Responses With fetch(). The one thing I found annoying with it, though, is that response.statusText always returns the generic error message associated with the error code. Most APIs, however, will generally return some kind of useful, more human friendly message in the body.

Here's a modification that will capture this message. The key is that rather than throwing an error, you just throw the response and then process it in the catch block to extract the message in the body:

fetch("/api/foo")
  .then( response => {
    if (!response.ok) { throw response }
    return response.json()  //we only get here if there is no error
 })

vasanthk

System Design Cheatsheet

Picking the right architecture = Picking the right battles + Managing trade-offs

Basic Steps

1. Clarify and agree on the scope of the system

• User cases (description of sequences of events that, taken together, lead to a system doing something useful)
  • Who is going to use it?
  • How are they going to use it?

tuxfight3r

Bash Shortcuts

Moving

command	description
ctrl + a	Goto BEGINNING of command line

macintux

• 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/
• http://scalingsystems.com/2011/09/07/reading-list-for-distributed-systems/

nifl

Answer by Jim Dennis on Stack Overflow question http://stackoverflow.com/questions/1218390/what-is-your-most-productive-shortcut-with-vim/1220118#1220118

Your problem with Vim is that you don't grok vi.

You mention cutting with yy and complain that you almost never want to cut whole lines. In fact programmers, editing source code, very often want to work on whole lines, ranges of lines and blocks of code. However, yy is only one of many way to yank text into the anonymous copy buffer (or "register" as it's called in vi).

The "Zen" of vi is that you're speaking a language. The initial y is a verb. The statement yy is a simple statement which is, essentially, an abbreviation for 0 y$:

0 go to the beginning of this line. y yank from here (up to where?)