Goals: Add links that are reasonable and good explanations of how stuff works. No hype and no vendor content if possible. Practical first-hand accounts of models in prod eagerly sought.

# Minimal example of getting a PostgREST API running from scratch for | |
# testing purposes. It uses docker to launch a postgres database and | |
# a postgrest api server. | |
# This should not be used to deploy a production system but to | |
# understand how postgrest works. In particular there is no security | |
# implemented, see the docs for more. | |
# https://postgrest.org/en/v4.4/ |
This optimizes a GLTF file that was exported by blender (or similar) by de-duplicating buffer views (i.e. chunks of bytes) that are equal and removing redundant accessors.
For example, 100 cubes of different scales/materials/rotations/etc should all end up using a single BufferGeometry in ThreeJS, which isn't the case with current GLTF exporters in Blender and parsers for ThreeJS.
In scenes with a lot of instancing, it can dramatically reduce total file size as well as render performance. In one test scene:
Before: 4.8MB file size, 832 THREE.Geometry
instances across 832 THREE.Mesh
objects
After: 661KB file size, 13 THREE.Geometry
instances across 832 THREE.Mesh
objects
This is a story about how I tried to use Go for scripting. In this story, I’ll discuss the need for a Go script, how we would expect it to behave and the possible implementations; During the discussion I’ll deep dive to scripts, shells, and shebangs. Finally, we’ll discuss solutions that will make Go scripts work.
While python and bash are popular scripting languages, C, C++ and Java are not used for scripts at all, and some languages are somewhere in between.
FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
One of the many things I do for my group at work is to take care of automating as many things as possible. It usually brings me a lot of satisfaction, mostly because I get a kick out of making people's lives easier.
But sometimes, maybe too often, I end up in drawn-out struggles with machines and programs. And sometimes, these struggles bring me to the edge of despair, so much so that I regularly consider living on a computer-less island growing vegetables for a living.
This is the story of how I had to install Pandoc in a CentOS 6 Docker container. But more generally, this is the story of how I think computing is inherently broken, how programmers (myself included) tend to think that their way is the way, how we're ultimately replicating what most of us think is wrong with society, building upon layers and layers of (best-case scenario) obscure and/or weak foundations.
*I would like to extend my gratitude to Google, StackOverflow, GitHub issues but mostly, the people who make the
#ifndef PROFILER | |
#define PROFILER | |
#include <map> | |
#include <string> | |
#include <utility> | |
#include <fstream> | |
#include <iomanip> | |
#include <osg/Timer> |
The prep-script.sh
will setup the latest Node and install the latest perf version on your Linux box.
When you want to generate the flame graph, run the following (folder locations taken from install script):
sudo sysctl kernel.kptr_restrict=0
# May also have to do the following:
# (additional reading http://unix.stackexchange.com/questions/14227/do-i-need-root-admin-permissions-to-run-userspace-perf-tool-perf-events-ar )
sudo sysctl kernel.perf_event_paranoid=0