Monthly Shaarli
February, 2019
type nvim >/dev/null 2>&1 && alias vim=nvim
replacing vim with the thing you want to replace and nvim with the thing you want to replace it with (and the thing you are checking for)
Tmux, tmuxinator setup and automation ideas. Tmuxinator projects explained. Fancy!
For restoration: https://blog.jamesthebard.net/restoring-with-the-borg/
Take your JavaScript to the next level. Gain an understanding of callbacks, higher order functions, closure, asynchronous and object-oriented JavaScript!
Rivers,
Terrain,
Heightmaps,
Cities,
Regions
Make vagrant use another folder / mount / directory
linked from https://news.ycombinator.com/item?id=19247633
vim, qutebrowser, vscode, sublime, intellij
similar to todoist in some ways
Learn how to build great engineering infrastructure to empower the products used by millions of people everyday.
Laracasts contains all sorts of Front-End and Full-Stack development tutorial series. Seems very good!
Learning path
Moving, editing, searching -> covers all the basic functionality of vim
Hidden on thoughtbot for some reason? Or hard to find. Other vim paths are available.
datasets, competitions, big data, ...
One of the advantages of an ECS architecture is that you are running your systems over only entities that those systems apply to which helps support a large number of entities at once.
If you're putting everything into an ECS system you'd still expect most of your walls to have very few components. For example they may have a render component, materials component, and a position component. Meanwhile a lot of your systems would apply to components that walls don't possess, like an AI component, a velocity component, etc. So if your ECS system stores components in a way that either caches a list of entities with that component or stores the component information in way where iterating over all entities with that component won't iterate over entities without that component you shouldn't see significant slowdown in that respect.
That said where you would see slowdown in this example is in doing things like calculating collision or computing line of sight. If your look-up for whether a tile is blocking is get all entities at position -> check each entity for a 'blocks sight' component then you're doing a lot of legwork for something that's already computationally expensive. If you have to do that every time an entity is trying to answer a question like "can I see x tile" or "can I move to y tile" that's going to sink your performance.
I think what you'd need to do in that case is plan ahead for this type of work build structures on top to help. For example you may build a component for static collision blockers (for entities that don't move or disappear often) and whenever an entity gains/loses that component or is added/removed with that component you recalculate a base collision map as a 1d/2d/3d boolean (or enum) array. That way you'd have that data already computed and when you need to do something like pathfinding you can use the pre-computed data structure rather than having to query a lot of information from the ECS system every time. Then if you need dynamic collision on top of that (for entities that move often) you could use a second component for that but it would be a much smaller amount of entities that you'd be looking at to incorporate that data.