wojteklu

Code is clean if it can be understood easily – by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability.

---

General rules

1. Follow standard conventions.
2. Keep it simple stupid. Simpler is always better. Reduce complexity as much as possible.
3. Boy scout rule. Leave the campground cleaner than you found it.
4. Always find root cause. Always look for the root cause of a problem.

Design rules

antirez

#ifndef __NN_H
#define __NN_H

/* Data structures.
 * Nets are not so 'dynamic', but enough to support
 * an arbitrary number of layers, with arbitrary units for layer.
 * Only fully connected feed-forward networks are supported. */
struct AnnLayer {
	int units;
	double *output;		/* output[i], output of i-th unit */

defuse

<?php

/*
 * This code is copied from 
 * http://www.warpconduit.net/2013/04/14/highly-secure-data-encryption-decryption-made-easy-with-php-mcrypt-rijndael-256-and-cbc/
 * to demonstrate an attack against it. Specifically, we simulate a timing leak
 * in the MAC comparison which, in a Mac-then-Encrypt (MtA) design, we show
 * breaks confidentiality.
 *
 * Slight modifications such as making it not serialize/unserialize and removing

tartakynov

import numpy as np
import pylab as pl
from numpy import fft
    
def fourierExtrapolation(x, n_predict):
    n = x.size
    n_harm = 10                     # number of harmonics in model
    t = np.arange(0, n)
    p = np.polyfit(t, x, 1)         # find linear trend in x
    x_notrend = x - p[0] * t        # detrended x

prakhar1989

Rich Hickey on becoming a better developer

Rich Hickey • 3 years ago

Sorry, I have to disagree with the entire premise here.

A wide variety of experiences might lead to well-roundedness, but not to greatness, nor even goodness. By constantly switching from one thing to another you are always reaching above your comfort zone, yes, but doing so by resetting your skill and knowledge level to zero.

Mastery comes from a combination of at least several of the following:

jvns

A lot of these are outright stolen from Edward O'Campo-Gooding's list of questions. I really like his list.

I'm having some trouble paring this down to a manageable list of questions -- I realistically want to know all of these things before starting to work at a company, but it's a lot to ask all at once. My current game plan is to pick 6 before an interview and ask those.

I'd love comments and suggestions about any of these.

I've found questions like "do you have smart people? Can I learn a lot at your company?" to be basically totally useless -- everybody will say "yeah, definitely!" and it's hard to learn anything from them. So I'm trying to make all of these questions pretty concrete -- if a team doesn't have an issue tracker, they don't have an issue tracker.

I'm also mostly not asking about principles, but the way things are -- not "do you think code review is important?", but "Does all code get reviewed?".

mattbaggott

##
## Sample code to demonstrate circular time plots in R
## matt@baggott.net
## Dec 22, 2012

# inspired by 
# http://stackoverflow.com/questions/2076370/most-underused-data-visualization

library(lubridate)
library(circular)

pepijndevos

(ns wiki.core
  (:use net.cgrand.moustache
        ring.adapter.jetty
        ring.util.response
        [ring.middleware params stacktrace reload]
        hiccup.core
        com.ashafa.clutch)
  (:require [clojure.string :as s])
  (:import org.pegdown.PegDownProcessor))