greenido

// Unfollow everyone on twitter.com, by Jamie Mason (https://twitter.com/fold_left)
// https://gist.github.com/JamieMason/7580315
//
// 1. Go to https://twitter.com/YOUR_USER_NAME/following
// 2. Open the Developer Console. (COMMAND+ALT+I on Mac)
// 3. Paste this into the Developer Console and run it
//
// Last Updated: 09 April 2020
(() => {
  const $followButtons = '[data-testid$="-unfollow"]';

greenido

Project Title

One Paragraph of project description goes here

Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

Demo

greenido

Docker - How to cleanup (unused) resources

Once in a while, you may need to cleanup resources (containers, volumes, images, networks) ...

delete volumes

// see: https://github.com/chadoe/docker-cleanup-volumes

$ docker volume rm $(docker volume ls -qf dangling=true)

$ docker volume ls -qf dangling=true | xargs -r docker volume rm

greenido

A product idea is something that you want to explore further --- you have some information but not all of it. This template provides questions to help get Product Managers focused and help them dive into the idea. It serves as a guide as PMs decide whether or not to pursue the opportunity and draft a Product Opportunity for their team.

Product Idea Template

The purpose of filling out this template is to set up a plan for further exploration. The questions are designed to help determine where to investigate further, and to encourage discussion with the team. This template is intentionally lightweight, can be used to quickly give ideas structure, and record ideas so they don't get lost. Product idea docs can be closed/archived and re-opened/unarchived later. They are not to be prioritized, rather product idea docs serve as a 'bulletin board' for ideas that come from other product opportunities, customer conversations, market research,

greenido

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

greenido

I hate almost all software. It's unnecessary and complicated at almost every layer. At best I can congratulate someone for quickly and simply solving a problem on top of the shit that they are given. The only software that I like is one that I can easily understand and solves my problems. The amount of complexity I'm willing to tolerate is proportional to the size of the problem being solved.

In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea. This is not however what we interact with. The complexity was not contained. Instead I deal with DBus and /usr/lib and Boost and ioctls and SMF and signals and volatile variables and prototypal inheritance and C99_FEATURES and dpkg and autoconf.

Those of us who build on top of these systems are adding to the complexity. Not only do you have to understand $LD_LIBRARY_PATH to make your system work but now you have to understand $NODE_PATH too - there's my little addit

greenido

#System Design Cheatsheet

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

##Basic Steps

1. Clarify -> 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?

greenido

Setup Mac OS X Mountain Lion or Mavericks

Edit: I few months ago I got a new laptop and did the same thing on Mavericks.

I just replaced the hard drive of my mbp and decided to do a clean install of Mountain Lion (10.8.5) since I was still using Snow Leopard (10.6.8).

I kinda regret for not using Boxen to automate the

greenido

/* Pounding heart animation */
@keyframes pound {
	to { transform: scale(1.8); }
}

.heart {
	display: inline-block;
	font-size: 50px;
	color: orange;
	animation: pound 1.3s infinite alternate;

greenido

<!DOCTYPE html>
<head>
<script>
var db;
// until we won't need this prefix mess
var indexedDB = window.indexedDB || window.webkitIndexedDB 
             || window.mozIndexedDB || window.msIndexedDB;
var IDBTransaction = window.IDBTransaction || 
                     window.webkitIDBTransaction;