Skip to content

Instantly share code, notes, and snippets.

@yorickdowne
yorickdowne / HallOfBlame.md
Last active September 15, 2025 14:02
Great and less great SSDs for Ethereum nodes

Overview

Syncing an Ethereum node is largely reliant on latency and IOPS, I/O Per Second, of the storage. Budget SSDs will struggle to an extent, and some won't be able to sync at all. IOPS can roughly be used as proxy of / predictor for latency. Measuring latency directly is arguably better.

This document aims to snapshot some known good and known bad models.

The drive lists are ordered by interface and then by capacity and alphabetically by vendor name, not by preference. The lists are not exhaustive at all. @mwpastore linked a filterable spreadsheet in comments that has a far greater variety of drives and their characteristics. Filter it by DRAM yes, NAND Type TLC, Form Factor M.2, and desired capacity.

For size, 4TB is a very conservative choice. The smaller 2TB drive should last an Ethereum full node until at least sometime 2026, with [pre-merge history expiry](https://hackmd.io/@hBXHLw_9Qq2va4pRtI4bI

@grGred
grGred / GasOptimizations.md
Last active February 19, 2025 15:47
Solidity gas optimizations and tricks

Upgrade pragma to latest Solidity compiler version


Using newer compiler versions and the optimizer gives gas optimizations and additional safety checks for free!

The advantages of versions 0.8.* over <0.8.0 are:

  • Safemath by default from 0.8.0 (can be more gas efficient than some library based safemath).
  • Low level inliner from 0.8.2, leads to cheaper runtime gas. Especially relevant when the contract has small functions. For example, OpenZeppelin libraries typically have a lot of small helper functions and if they are not inlined, they cost an additional 20 to 40 gas because of 2 extra jump instructions and additional stack operations needed for function calls.
  • Optimizer improvements in packed structs: Before 0.8.3, storing packed structs, in some cases used an additional storage read operation. After [EIP-

Git DMZ Flow

I've been asked a few times over the last few months to put together a full write-up of the Git workflow we use at RichRelevance (and at Precog before), since I have referenced it in passing quite a few times in tweets and in person. The workflow is appreciably different from GitFlow and its derivatives, and thus it brings with it a different set of tradeoffs and optimizations. To that end, it would probably be helpful to go over exactly what workflow benefits I find to be beneficial or even necessary.

  • Two developers working on independent features must never be blocked by each other
    • No code freeze! Ever! For any reason!
  • A developer must be able to base derivative work on another developer's work, without waiting for any third party
  • Two developers working on inter-dependent features (or even the same feature) must be able to do so without interference from (or interfering with) any other parties
  • Developers must be able to work on multiple features simultaneously, or at lea
@Decoherence
Decoherence / Servant_JSON_API.hs
Last active January 17, 2020 13:07
Haskell: Bookstore REST API with PostgreSQL backend using Servant
{-# LANGUAGE DataKinds #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE PolyKinds #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE TypeOperators #-}
import Control.Applicative
import Control.Monad.IO.Class
import Data.Aeson
@marchawkins
marchawkins / get-weather-by-address.html
Last active July 29, 2021 02:28
Using the OpenWeatherMap and Google's geolocation APIs to get the current weather for the user-specified location. The user inputs a location, which is geocoded using Google Maps API. Uses the OpenWeatherMap API ((http://openweathermap.org/)) to get the data. Data is returned in JSON format. Most major browsers supported, including IE9, Chrome, …
<div class="row">
<div class="col-md-2 col-sm-2 col-xs-2">
<p><button class="btn btn-primary btn-sm" id="get-weather-btn"><span>Get Weather</span></button></p>
</div><!-- .col -->
<div class="col-md-10 col-sm-10 col-xs-10">
<div class="panel panel-default">
<div class="panel-heading">Weather &amp; Location Response</div>
<div class="panel-body">
<p>Enter Address: <input id="address" type="text" class="form-control"/></p>
<p>Lat/Long: <input id="location-lat-long" type="text" class="form-control"/></p>
@adamwiggins
adamwiggins / adams-heroku-values.md
Last active September 6, 2025 20:29
My Heroku values

Make it real

Ideas are cheap. Make a prototype, sketch a CLI session, draw a wireframe. Discuss around concrete examples, not hand-waving abstractions. Don't say you did something, provide a URL that proves it.

Ship it

Nothing is real until it's being used by a real user. This doesn't mean you make a prototype in the morning and blog about it in the evening. It means you find one person you believe your product will help and try to get them to use it.

Do it with style