jboner

Latency Comparison Numbers (~2012)
----------------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy             3,000   ns        3 us
Send 1K bytes over 1 Gbps network       10,000   ns       10 us
Read 4K randomly from SSD*             150,000   ns      150 us          ~1GB/sec SSD

isaacsanders

This is a post by Joel Spolsky. The original post is linked at the bottom.

This is such a common question here and elsewhere that I will attempt to write the world's most canonical answer to this question. Hopefully in the future when someone on answers.onstartups asks how to split up the ownership of their new company, you can simply point to this answer.

The most important principle: Fairness, and the perception of fairness, is much more valuable than owning a large stake. Almost everything that can go wrong in a startup will go wrong, and one of the biggest things that can go wrong is huge, angry, shouting matches between the founders as to who worked harder, who owns more, whose idea was it anyway, etc. That is why I would always rather split a new company 50-50 with a friend than insist on owning 60% because "it was my idea," or because "I was more experienced" or anything else. Why? Because if I split the company 60-40, the company is going to fail when we argue ourselves to death. And if you ju

jimmychu0807

use std::str;

fn main() {
  // -- FROM: vec of chars --
  let src1: Vec<char> = vec!['j','{','"','i','m','m','y','"','}'];
  // to String
  let string1: String = src1.iter().collect::<String>();
  // to str
  let str1: &str = &src1.iter().collect::<String>();
  // to vec of byte

shaneutt

This is free and unencumbered software released into the public domain.

Anyone is free to copy, modify, publish, use, compile, sell, or
distribute this software, either in source code form or as a compiled
binary, for any purpose, commercial or non-commercial, and by any
means.

In jurisdictions that recognize copyright laws, the author or authors
of this software dedicate any and all copyright interest in the
software to the public domain. We make this dedication for the benefit

bishboria

These links no longer work. Springer have pulled the free plug.

Graduate texts in mathematics

duplicates = multiple editions

A Classical Introduction to Modern Number Theory, Kenneth Ireland Michael Rosen

A Classical Introduction to Modern Number Theory, Kenneth Ireland Michael Rosen

jonleighton

// Converts an ArrayBuffer directly to base64, without any intermediate 'convert to string then
// use window.btoa' step. According to my tests, this appears to be a faster approach:
// http://jsperf.com/encoding-xhr-image-data/5

/*
MIT LICENSE

Copyright 2011 Jon Leighton

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

mikepea

Pull Request Etiquette

Why do we use a Pull Request workflow?

PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.

Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories

Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.

gtallen1187

"Scar Tissues Make Relationships Wear Out"

04/26/2103. From a lecture by Professor John Ousterhout at Stanford, class CS142.

This is my most touchy-feely thought for the weekend. Here’s the basic idea: It’s really hard to build relationships that last for a long time. If you haven’t discovered this, you will discover this sooner or later. And it's hard both for personal relationships and for business relationships. And to me, it's pretty amazing that two people can stay married for 25 years without killing each other.

[Laughter]

> But honestly, most professional relationships don't last anywhere near that long. The best bands always seem to break up after 2 or 3 years. And business partnerships fall apart, and there's all these problems in these relationships that just don't last. So, why is that? Well, in my view, it’s relationships don't fail because there some single catastrophic event to destroy them, although often there is a single catastrophic event around the the end of the relation

movitto

#!/usr/bin/ruby
# Read keyboard presses / release / holds on Linux
# Released under the MIT License

# Use binary_struct to process blobs
require_relative 'binary_struct'

##################!!!!######################
#!!!!CHANGE ME TO YOUR KEYBOARD DEVICE!!!!!#
############################################

tommyettinger

/*  Written in 2017 by Tommy Ettinger (tommy.ettinger@gmail.com)

To the extent possible under law, the author has dedicated all copyright
and related and neighboring rights to this software to the public domain
worldwide. This software is distributed without any warranty.

See <http://creativecommons.org/publicdomain/zero/1.0/>. */

#include <stdint.h>