- View: Also called a "template", a file that contains markup (like HTML) and optionally additional instructions on how to generate snippets of HTML, such as text interpolation, loops, conditionals, includes, and so on.
- View engine: Also called a "template library" or "templater", ie. a library that implements view functionality, and potentially also a custom language for specifying it (like Pug does).
- HTML templater: A template library that's designed specifically for generating HTML. It understands document structure and thus can provide useful advanced tools like mixins, as well as more secure output escaping (since it can determine the right escaping approach from the context in which a value is used), but it also means that the templater is not useful for anything other than HTML.
- String-based templater: A template library that implements templating logic, but that has no understanding of the content it is generating - it simply concatenates together strings, potenti
Latency Comparison Numbers (~2012) | |
---------------------------------- | |
L1 cache reference 0.5 ns | |
Branch mispredict 5 ns | |
L2 cache reference 7 ns 14x L1 cache | |
Mutex lock/unlock 25 ns | |
Main memory reference 100 ns 20x L2 cache, 200x L1 cache | |
Compress 1K bytes with Zippy 3,000 ns 3 us | |
Send 1K bytes over 1 Gbps network 10,000 ns 10 us | |
Read 4K randomly from SSD* 150,000 ns 150 us ~1GB/sec SSD |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
This is a compiled list of falsehoods programmers tend to believe about working with time.
Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.
- There are always 24 hours in a day.
- February is always 28 days long.
- Any 24-hour period will always begin and end in the same day (or week, or month).
I have a pet project I work on, every now and then. CNoEvil.
The concept is simple enough.
What if, for a moment, we forgot all the rules we know. That we ignore every good idea, and accept all the terrible ones. That nothing is off limits. Can we turn C into a new language? Can we do what Lisp and Forth let the over-eager programmer do, but in C?
# to generate your dhparam.pem file, run in the terminal | |
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048 |
from datetime import datetime | |
import urllib.request | |
import base64 | |
import json | |
import time | |
import os | |
webui_server_url = 'http://127.0.0.1:7860' | |
out_dir = 'api_out' |
@echo off | |
echo Uninstalling KB3075249 (telemetry for Win7/8.1) | |
start /w wusa.exe /uninstall /kb:3075249 /quiet /norestart | |
echo Uninstalling KB3080149 (telemetry for Win7/8.1) | |
start /w wusa.exe /uninstall /kb:3080149 /quiet /norestart | |
echo Uninstalling KB3021917 (telemetry for Win7) | |
start /w wusa.exe /uninstall /kb:3021917 /quiet /norestart | |
echo Uninstalling KB3022345 (telemetry) | |
start /w wusa.exe /uninstall /kb:3022345 /quiet /norestart | |
echo Uninstalling KB3068708 (telemetry) |
Macro hygiene is the concept of macros that work in all contexts; they don't affect and aren't affected by anything around them. Ideally all macros would be fully hygienic, but there are lots of pitfalls and traps that make it all too easy to accidentally write unhygienic macros. This guide attempts to provide a comprehensive resource for writing the most hygienic macros.
First, a little aside on the details of Rust's module system, and specifically paths; it is