AnatomicJC

Create a dedicated ZFS docker pool with deduplication disabled in case of dedup enabled on your system:

zfs create -o mountpoint=/var/lib/docker -o dedup=off rpool/docker

Sometimes, you don't want ZFS for docker storage. ZFS can be sadly quite painful with Docker in Docker and similar scenarios. It might be best to avoid the problem by creating a volume in your ZFS pool, formatting that volume to ext4, and having docker use "overlay2" on top of that, instead of "zfs".

zfs create -s -V 30G rpool/docker

mkfs.ext4 /dev/zvol/rpool/docker

SanderTheDragon

#!/bin/sh

# SPDX-FileCopyrightText: 2017-2024 SanderTheDragon <sanderthedragon@zoho.com>
#
# SPDX-License-Identifier: MIT

arch=$(dpkg --print-architecture)
echo "Detected architecture: $arch"

case "$arch" in

philippmuench

# add this line to your Dockerfile (you also need to install Rbase)
RUN R -e 'install.packages("packrat" , repos="http://cran.us.r-project.org"); packrat::restore()'

pzrq

# -*- coding: utf-8 -*-
"""
# usage: python mro_exploration.py
# https://github.com/pzrq/

Better PyCharm mixin handling would make it far more useful for 
Django Class-Based Views, Managers, and in contexts others have identified
such as Werkzeug.
https://youtrack.jetbrains.com/issue/PY-7712

chantastic

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't

nikic

Why objects (usually) use less memory than arrays in PHP

This is just a small post in response to [this tweet][tweet] by Julien Pauli (who by the way is the release manager for PHP 5.5). In the tweet he claims that objects use more memory than arrays in PHP. Even though it can be like that, it's not true in most cases. (Note: This only applies to PHP 5.4 or newer.)

The reason why it's easy to assume that objects are larger than arrays is because objects can be seen as an array of properties and a bit of additional information (like the class it belongs to). And as array + additional info > array it obviously follows that objects are larger. The thing is that in most cases PHP can optimize the array part of it away. So how does that work?

The key here is that objects usually have a predefined set of keys, whereas arrays don't:

stantonk

<!-- Drop this in ~/Library/Preferences/PyCharm20/tools -->
<!-- make sure you set the path to flake8 executable for your machine in the COMMAND option -->

<?xml version="1.0" encoding="UTF-8"?>
<toolSet name="Flake8">
  <tool name="Flake8 File" showInMainMenu="true" showInEditor="true" showInProject="true" showInSearchPopup="false" disabled="false" useConsole="true" synchronizeAfterRun="true">
    <exec>
      <option name="COMMAND" value="/usr/local/share/python/flake8" />
      <option name="PARAMETERS" value="--max-line-length=120 --ignore=E301,E302,E261,E262,W404 $FileDir$/$FileName$" />
      <option name="WORKING_DIRECTORY" value="$FileDir$" />