lmumar

//
// Author:   Jonathan Blow
// Version:  1
// Date:     31 August, 2018
//
// This code is released under the MIT license, which you can find at
//
//          https://opensource.org/licenses/MIT
//
//

lmumar

# Encoding: utf-8

#
# idle.rb
# 
# goal:
#   Ruby script to test how to fetch IMAP mails with IDLE mode.
#   IMAP IDLE allow a sort of "push" / "real-time" delivery.
#
#   I used the script to test LATENCY (end-to-end delivery times)

lmumar

[Unit]
Description=Puma Rails Server
After=network.target

[Service]
Type=simple
User=deploy
WorkingDirectory=/home/deploy/app/current
ExecStart=/home/deploy/.rbenv/bin/rbenv exec bundle exec puma -C /home/deploy/app/shared/config/puma.rb
ExecStop=/home/deploy/.rbenv/bin/rbenv exec bundle exec pumactl -S /home/deploy/app/shared/tmp/pids/puma.state stop

lmumar

How not to fuck up OAuth2

I've seen a number of articles posted here recently that just give terrible advice when it comes to OAuth2, so I figured I'd make this so people would dick themselves over.

The reason people do this, is because they are just writing filler nonsense content in the hopes you'll click on the website. They don't care if the content is solid because they just want you to see the ads.

As for my credentials, I work for a major fintech company with part of my duties being to help developers get set up with OAuth2 in their applications.

If you aren't a lazy fuck, just read this, and the next section on decoupling. Otherwise I've summarised the important bits later on.

lmumar

const redisClient = redis.createClient(REDIS_URL);
const listeners = Object.create(null);

function addListener(channel, listener) {
  if (!listeners[channel]) {
    listeners[channel] = [];
    redisClient.subscribe(channel);
  }

  listeners[channel].push(listener);

lmumar

import EXIF from 'exif-js';

const hasBlobConstructor = typeof (Blob) !== 'undefined' && (function checkBlobConstructor() {
    try {
        return Boolean(new Blob());
    } catch (error) {
        return false;
    }
}());

lmumar

Turning PostgreSQL into a queue serving 10,000 jobs per second

RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.

On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.

So, many developers have started going straight t

lmumar

//
//  EmailAddress.swift
//  MyDB
//
//  Created by Lord Norlan Mumar on 7/13/19.
//  Copyright © 2019 Lord Norlan Mumar. All rights reserved.
//

import Foundation
import RealmSwift

lmumar

import Foundation

indirect enum Tree {
    case empty
    case node(data: Int, left: Tree, right: Tree)
}

extension Tree: CustomStringConvertible {
    var description: String {
        switch self {

lmumar

import Foundation

internal protocol _AnyComparableBox {
    var _canonicalBox: _AnyComparableBox { get }
    func _isEqual(to box: _AnyComparableBox) -> Bool
    func _precede(to box: _AnyComparableBox) -> Bool
    func _unbox<T: Comparable>() -> T?
}

extension _AnyComparableBox {