Skip to content

Instantly share code, notes, and snippets.

View sgsfak's full-sized avatar

Stelios Sfakianakis sgsfak

  • Heraklion Greece
  • 04:59 (UTC +02:00)
  • LinkedIn in/sgsfak
View GitHub Profile
@sgsfak
sgsfak / rrysnc.sh
Created November 14, 2022 10:25 — forked from michaelherger/rrysnc.sh
rrsync replacement without perl, useful for limited environment like CoreOS
#!/bin/sh
# Copyright (C) 2004 Joe Smith <[email protected]>
# Copyright (C) 2004-2015 Wayne Davison <[email protected]>
# Copyright (C) 2016-2018 YOSHIOKA Takuma <[email protected]>
#
# 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
sgsfak / leetcode-Report-Contiguous-Dates.sql
Last active July 11, 2020 12:28
Leetcode: report-contiguous-dates
-- 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
sandren / tailwind.md
Last active October 12, 2024 17:10
Tailwind CSS best practices

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
ilevantis / bedtools_cheatsheet.md
Last active September 13, 2024 19:19
Bedtools cheatsheet

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
mattmc3 / modern_sql_style_guide.md
Last active November 14, 2024 20:21
Modern SQL Style Guide
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
giampaolotrapasso / Designing Event-Driven Systems links.md
Created August 1, 2018 09:56
List of links from Designing Event-Driven Systems by Ben Stopford

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.

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.

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
robertpainsi / commit-message-guidelines.md
Last active November 16, 2024 11:48
Commit message guidelines

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