Thread pools on the JVM should usually be divided into the following three categories:
- CPU-bound
- Blocking IO
- Non-blocking IO polling
Each of these categories has a different optimal configuration and usage pattern.
#!/bin/bash | |
# install qemu utils | |
sudo apt install qemu-utils | |
# install nbd client | |
sudo apt install nbd-client |
(EDIT: Besides Reddit, I've also put this up on Github Gist)
So while looking for information on security keys before getting one myself, I got very confused reading about all the different modes and advertised features of Yubikeys and other similar dongles. The official documentation tends to be surprisingly convoluted at times, weirdly organized and oddly shy about a few of the limitations of these keys (which I'm making a point of putting front and center). Now that I have one, I decided to write down everything I figured out in order to help myself (and hopefully some other people reading this) make sense of all this.
Since I'm partly writing these notes for myself, there might be some back and forth between "exp
Locate the section for your github remote in the .git/config
file. It looks like this:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@github.com:joyent/node.git
Now add the line fetch = +refs/pull/*/head:refs/remotes/origin/pr/*
to this section. Obviously, change the github url to match your project's URL. It ends up looking like this:
Solarized | |
#FDF6E3,#EEE8D5,#93A1A1,#FDF6E3,#EEE8D5,#657B83,#2AA198,#DC322F | |
Solarized Dark | |
#073642,#002B36,#B58900,#FDF6E3,#CB4B16,#FDF6E3,#2AA198,#DC322F | |
PRs are a great way of sharing information, and can help us be aware of the changes that are occuring in our codebase. They are also an excellent way of getting peer review on the work that we do, without the cost of working in direct pairs.
Ultimately though, the primary reason we use PRs is to encourage quality in the commits that are made to our code repositories
Done well, the commits (and their attached messages) contained within tell a story to people examining the code at a later date. If we are not careful to ensure the quality of these commits, we silently lose this ability.
Hi, I'm mcpower. I've done Advent of Code seriously for two years now in Python, placing 9th in 2018 and 12th in 2017. This year, I'm taking a break from aiming for the leaderboard - while it's fun and all, it is a bit stressful at times (the good kind of stress, though!). As such, I'd like to share a few tips for anyone wanting to aim for the leaderboard.
This is everything that worked for me. Your mileage may vary, though - don't take this as gospel, see what works for you.
Go fast.
This is a guide for Scala and Java development on Windows, using Windows Subsystem for Linux, although a bunch of it is applicable to a VirtualBox / Vagrant / Docker subsystem environment. This is not complete, but is intended to be as step by step as possible.
Read the entire Decent Security guide, and follow the instructions, especially:
package effects | |
import cats.{MonadError, StackSafeMonad} | |
import scala.concurrent.{ExecutionContext, Future} | |
import scala.util.{Failure, Success, Try} | |
final case class F[+E, +A](value: Future[Either[E, A]]) extends AnyVal { | |
def fold[B](fe: E => B, fa: A => B)(implicit ec: ExecutionContext): Future[B] = value.map { |
Usage... | |
Vcxsrv [:<display>] [option] | |
:display-number | |
Vcxsrv runs as the given display-number, which defaults to 0. | |
To run multiple instances, use unique display-numbers. | |
-a # default pointer acceleration (factor) | |
-ac disable access control restrictions | |
-audit int set audit trail level |