See how a minor change to your commit message style can make you a better programmer.
Format: <type>(<scope>): <subject>
<scope>
is optional
So, with credit to the Factorio wiki and cbednarski's helpful gist, I managed to eventually setup a Factorio headless server. Although, I thought the process could be nailed down/simplified to be a bit more 'tutorialised' and also to document how I got it all working for my future records.
The specific distro/version I'm using for this guide being Ubuntu Server 16.04.1 LTS
. Although, that shouldn't matter, as long as your distro supports systemd
(just for this guide, not a Factorio headless requirement, although most distros use it as standard now).
The version of Factorio I shall be using is 0.14.20
, although should work for any version of Factorio 0.14.12
and higher.
Just a note to newcomers: If there are any issues with the installation steps, people in the comments are doing a good job
Magic words:
psql -U postgres
Some interesting flags (to see all, use -h
or --help
depending on your psql version):
-E
: will describe the underlaying queries of the \
commands (cool for learning!)-l
: psql will list all databases and then exit (useful if the user you connect with doesn't has a default database, like at AWS RDS)var groupBy = function(data, key) { // `data` is an array of objects, `key` is the key (or property accessor) to group by | |
// reduce runs this anonymous function on each element of `data` (the `item` parameter, | |
// returning the `storage` parameter at the end | |
return data.reduce(function(storage, item) { | |
// get the first instance of the key by which we're grouping | |
var group = item[key]; | |
// set `storage` for this instance of group to the outer scope (if not empty) or initialize it | |
storage[group] = storage[group] || []; | |
-- Create a group | |
CREATE ROLE readaccess; | |
-- Grant access to existing tables | |
GRANT USAGE ON SCHEMA public TO readaccess; | |
GRANT SELECT ON ALL TABLES IN SCHEMA public TO readaccess; | |
-- Grant access to future tables | |
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO readaccess; |
While the following structure is not an absolute requirement or enforced by the tools, it is a recommendation based on what the JavaScript and in particular Node community at large have been following by convention.
Beyond a suggested structure, no tooling recommendations, or sub-module structure is outlined here.
lib/
is intended for code that can run as-issrc/
is intended for code that needs to be manipulated before it can be usedWarning: These views are highly oppinated and might have some slightly incorrect facts. My experience with typescript was about 2 weeks in Node and a week in angular2.
TypeScript is implementing their own take on JavaScript. Some of the things they are writing will likely never make it in an official ES* spec either.
Technologies that have competing spec / community driven development have a history of failing; take: Flash, SilverLight, CoffeeScript, the list goes on. If you have a large code base, picking TypeScript is something your going to be living with for a long time. I can take a bet in 3 years JavaScript will still be around without a doubt.
Its also worth noting that they have built some things like module system and as soon as the spec came out they ditched it and started using that. Have fun updating!
**/node_modules
prettier --write "**/*.js"
*Don't forget the quotes.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