sgsfak

#!/bin/sh

# Copyright (C) 2004 Joe Smith <js-cgi@inwap.com>
# Copyright (C) 2004-2015 Wayne Davison <wayned@samba.org>
# Copyright (C) 2016-2018 YOSHIOKA Takuma <tashioka.256@gmail.com>
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.

sgsfak

-- Problem description found at https://code.dennyzhang.com/report-contiguous-dates
-- Schema and test data:
-- CREATE TABLE Failed(fail_date DATE);
-- CREATE TABLE Succeeded(success_date DATE);
-- INSERT INTO Failed VALUES ('2018-12-28'), ('2018-12-29'), ('2019-01-04'), ('2019-01-05');
-- INSERT INTO Succeeded VALUES ('2018-12-30'),('2018-12-31'),('2019-01-01'),('2019-01-02'),('2019-01-03'),('2019-01-06');

WITH RECURSIVE 
  tasks(dt, state) AS 
        (SELECT success_date, 'succeeded' 

sandren

Tailwind CSS best practices

Utility classes

1. When writing a string of multiple utility classes, always do so in an order with meaning. The "Concentric CSS" approach works well with utility classes (i.e,. 1. positioning/visibility 2. box model 3. borders 4. backgrounds 5. typography 6. other visual adjustments). Once you establish a familiar pattern of ordering, parsing through long strings of utility classes will become much, much faster so a little more effort up front goes a long way!

2. Always use fewer utility classes when possible. For example, use mx-2 instead of ml-2 mr-2 and don't be afraid to use the simpler p-4 lg:pt-8 instead of the longer, more complicated pt-4 lg:pt-8 pr-4 pb-4 pl-4.

3. Prefix all utility classes that will only apply at a certain breakpoint with that breakpoint's prefix. For example, use block lg:flex lg:flex-col lg:justify-center instead of block lg:flex flex-col justify-center to make it very clear that the flexbox utilities are only applicable at the

ilevantis

Bedtools Cheatsheet

General:

Tools	Description
flank	Create new intervals from the flanks of existing intervals.
slop	Adjust the size of intervals.
shift	Adjust the position of intervals.
subtract	Remove intervals based on overlaps b/w two files.

mattmc3

layout	author	title	revision	version	description
default	mattmc3	Modern SQL Style Guide	2019-01-17	1.0.1	A guide to writing clean, clear, and consistent SQL.

Modern SQL Style Guide

giampaolotrapasso

List of links from Designing Event-Driven Systems by Ben Stopford

Designing Event-Driven Systems book by Ben Stopford contains a lot of useful links to papers, books, documentation and definitions related to event driven design and Kafka. I just extracted them as reference for the future and added some groups to show them better.

You can read the book for free

• A Crystal Ball to Prioritise Technical Debt in Monoliths or Microservices: Adam Tornhill's Thoughts
• Brewer's CAP Theorem <= :julianbrowne

djspiewak

Very briefly...

In reply to some of the points from here. I understand the body of the post was more nuanced, though most of my arguments extend to the long form. Take this as an archetype of a full response.

Quick prefix though... I'm going to mention Haskell a few times. This isn't because I believe Haskell is a perfect language by any stretch of the imagination (if nothing else, its ecosystem is a hot mess). It's just a convenient noun that represents the category of language I'm thinking about.

solving a real-world problem => must use non-elegant models

I really hate this argument, because it starts out by implying that one party (presumably the untyped language users) are doing "real" work, while the other party (presumably the static typers) are not. Last time I checked, the code I write interacts with the real world. That is literally the whole point.

djspiewak

Thread Pools

Thread pools on the JVM should usually be divided into the following three categories:

1. CPU-bound
2. Blocking IO
3. Non-blocking IO polling

Each of these categories has a different optimal configuration and usage pattern.

FaKleiser

AD-XX: <TOPIC - short, concise summary>

• Date: <DATE - when the decision was made>
• Driver: <DRIVER - list a single person driving consenus and decision making>
• Stakeholders: <STAKEHOLDERS - list all relevant stakeholders affected by this decision>
• Status: [PROPOSED | DECIDED | SUPERSEDED]
• Categories: <CATEGORIES - use a simple grouping to help organize the set of decisions (e.g. backend, payment, user management, ...)>
• Outcome: <OUTCOME - once decided, provide a short summary of the decision outcome here>

Context

robertpainsi

Commit Message Guidelines

Short (72 chars or less) summary

More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).

Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages