There're a lot of combinations to manage your email with emacs, but this works for me. I've a backup and I can manage my daily email.
The stack:
- emacs
- offlineimap
- mu
- mu4e
ּ_בּ | |
בּ_בּ | |
טּ_טּ | |
כּ‗כּ | |
לּ_לּ | |
מּ_מּ | |
סּ_סּ | |
תּ_תּ | |
٩(×̯×)۶ | |
٩(̾●̮̮̃̾•̃̾)۶ |
(ns prefix-tree) | |
;Record representing a node in the prefix tree. | |
;strings: The set of strings that the present node represents | |
;edges: Map representing edges emanating from this node. | |
;The key being the first letter of the label and the value being the label and the actual node being pointed to." | |
(defrecord Node [strings edges]) | |
(defn shorter-string [a b] | |
"Return the shorter string of the two being passed in." |
FRP to me means building your app by transforming values over time, from the input to the current state to the display.
This implementation is based on a the [graphics][1] library and is heavily inspired by [Elm][2]
A full implementation of TodoFRP can be found [online at Raynos/graphics example server][3]
This is a mix between two sources:
basically the first resource is great but didn't work for me: I had to remove the trailing "/*" in the resource string to make it work. I also noticed that setting the policy on the source bucket was sufficient. In the end these are the exact steps I followed to copy data between two buckets on two accounts
Basically the idea there is:
This post also appears on lisper.in.
Reader macros are perhaps not as famous as ordinary macros. While macros are a great way to create your own DSL, reader macros provide even greater flexibility by allowing you to create entirely new syntax on top of Lisp.
Paul Graham explains them very well in [On Lisp][] (Chapter 17, Read-Macros):
The three big moments in a Lisp expression's life are read-time, compile-time, and runtime. Functions are in control at runtime. Macros give us a chance to perform transformations on programs at compile-time. ...read-macros... do their work at read-time.
package astar | |
import "container/heap" | |
type NodeQueue []Node | |
func NewNodeQueue() NodeQueue { | |
return make(NodeQueue, 0, 1000) | |
} |
A checklist for designing and developing internet scale services, inspired by James Hamilton's 2007 paper "On Desgining and Deploying Internet-Scale Services."
My largest Sidekiq application had a memory leak and I was able to find and fix it in just few hours spent on analyzing Ruby's heap. In this post I'll show my profiling setup.
As you might know Ruby 2.1 introduced a few great changes to ObjectSpace, so now it's much easier to find a line of code that is allocating too many objects. Here is great post explaining how it's working.
I was too lazy to set up some seeding and run it locally, so I checked that test suite passes when profiling is enabled and pushed debugging to production. Production environment also suited me better since my jobs data can't be fully random generated.
So, in order to profile your worker, add this to your Sidekiq configuration:
if ENV["PROFILE"]
/***************************************** | |
/* DOM touch support module | |
/*****************************************/ | |
if (!window.CustomEvent) { | |
window.CustomEvent = function (event, params) { | |
params = params || { bubbles: false, cancelable: false, detail: undefined }; | |
var evt = document.createEvent('CustomEvent'); | |
evt.initCustomEvent(event, params.bubbles, params.cancelable, params.detail); | |
return evt; | |
}; |