Kia. themojilla

Notes on Rich Hickey's "Simple Made Easy" talk

talk: https://www.youtube.com/watch?v=rI8tNMsozo0

slides: https://www.slideshare.net/evandrix/simple-made-easy

"Simplicity is prerequisite for reliability" -- Dijkstra

Simple:

vs complex

Ideas

I have collected and moderated these ideas from various public sources and put into one place so that problem solvers and solution developers may find inspirations. Because I wish to update it regularly, I have setup as a single page wiki. You may try these ideas on hackathons/competitions/research; some are quite intense problems and some are not. Many of the problems were prepared keeping Dhaka/Bangladesh in mind, but of course can be applied to just about any underdeveloped/developing and sometimes developed countries.

Categories:

Eradicate Extreme Poverty and Hunger
Education
Healthcare
Governance

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

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

Design rules

Here is a non-exhaustive list of books that have influenced how I think about software.

RESTful Web Services - Leonard Richardson - THE book on REST
Clean Code - Robert C. Martin - The book on how to write code sensibly, vital for new programmers
97 Things Every Programmer Should Know - Kevlin Henney - Tips and tricks, similar to Clean code but much more bit-size. Perfect toilet reading
[Don't Make Me Think! - Steve Krug](http://www.amazon.co.uk/Dont-Make-Me-Think-Usability/dp/0321965515/ref=sr_1_1?s=books&ie=UTF8&qid=1439306124&sr=1-1&keywords=Don%27t+Make+Me+Think%21+-+Steve+K

FWIW: I'm not the author of the content presented here (which is an outline from Edmond Lau's book). I've just copy-pasted it from somewhere over the Internet, but I cannot remember what exactly the original source is. I was also not able to find the author's name, so I cannot give him/her the proper credits.

Effective Engineer - Notes

By Edmond Lau
Highly Recommended 👍
http://www.theeffectiveengineer.com/

What's an Effective Engineer?

What forces layout / reflow

All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.

Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.

Element APIs

Getting box metrics

elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent

	// Based on: https://kyleshevlin.com/snippets/spacer
	// PurgeCSS will remove the Tailwind margin classes from a production build.
	// In order to keep them, you can safelist them via: https://tailwindcss.com/docs/optimizing-for-production#purge-css-options

	type Margin = number \| string;

	type Margins = {
	readonly top?: Margin;
	readonly right?: Margin;
	readonly bottom?: Margin;

	export default async function tryCatch<T>(
	promise: Promise<T>,
	): Promise<{ error: Error } \| { data: T }> {
	try {
	return { data: await promise };
	} catch (error) {
	return { error };
	}
	}

	const fsp = require("fs").promises;
	const path = require("path");
	const { execSync } = require("child_process");

	const chalk = require("chalk");
	const Confirm = require("prompt-confirm");
	const jsonfile = require("jsonfile");
	const semver = require("semver");

	const packagesDir = path.resolve(__dirname, "../packages");

	module.exports = {
	plugins: [
	require("tailwindcss"),
	require("autoprefixer"),
	process.env.NODE_ENV === "production" && require("cssnano"),
	].filter(Boolean),
	};