It's true.
I spent several years of my software career trying to find better ways of managing my time and using it efficiently. I wanted to make sure I was spending the most time on what mattered most.
Lately, I’ve come to realize how flawed this line of thinking is.
It’s not about time. It’s about energy.
#!/bin/bash | |
### | |
# This script utilizes apprise (https://github.com/caronc/apprise) to send notifications | |
# You need to have apprise available for the user sonarr operates under. | |
# I installed it via `sudo pip install --system apprise` although the python | |
# community really dislikes it when you do that. Recommended installation would be | |
# something along the lines of: | |
# | |
# sudo su sonarr -s /bin/bash | |
# pip install --user apprise |
#pragma once | |
#include <memory> | |
#include <utility> | |
#include <type_traits> | |
#include <functional> // TODO: Stop using functional. | |
template <class T> | |
struct default_clone { | |
T* operator()(const T* ptr) const |
These are some thoughts on Kanban after reading [Priming Kanban][1].
Most important thing to remember:
#Kanban is a change method!#
Methodology | Kind of process | Change adoption |
---|---|---|
Plan Methodology | Too much proces | Resist change |
Agile | Just enough process | Change is the fuel that keeps the engine running |
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
;SMBDIS.ASM - A COMPREHENSIVE SUPER MARIO BROS. DISASSEMBLY | |
;by doppelganger (doppelheathen@gmail.com) | |
;This file is provided for your own use as-is. It will require the character rom data | |
;and an iNES file header to get it to work. | |
;There are so many people I have to thank for this, that taking all the credit for | |
;myself would be an unforgivable act of arrogance. Without their help this would | |
;probably not be possible. So I thank all the peeps in the nesdev scene whose insight into | |
;the 6502 and the NES helped me learn how it works (you guys know who you are, there's no |
using System; | |
using System.Net; | |
using System.Text; | |
using System.Threading; | |
namespace ExampleSimpleWebserver | |
{ | |
class Program | |
{ | |
static void Main (string[] args) |
local function scale(x, min1, max1, min2, max2) | |
return min2 + ((x - min1) / (max1 - min1)) * (max2 - min2) | |
end | |
local function distance(x1, y1, x2, y2) | |
return math.sqrt((x2 - x1) ^ 2 + (y2 - y1) ^ 2) | |
end | |
function radialGradient(radius) | |
local data = love.image.newImageData(radius * 2, radius * 2) |