Authorization and Authentication are hard. when you only have to implement them once (as you do within a monolith) instead of over and over again, it makes the developer happy :-), and maybe leads to less implementation failures.
When you have a bunch of microservices, this is something that has to be considered.
Implement it once or in every microservice, or something in between?
The standard names for indexes in PostgreSQL are:
{tablename}_{columnname(s)}_{suffix}
where the suffix is one of the following:
pkeyfor a Primary Key constraint;keyfor a Unique constraint;exclfor an Exclusion constraint;idxfor any other kind of index;
| title | Unit testing Angular.js app with node.js, mocha, angular-mocks and jsdom |
|---|---|
| slug | unit-testing-angular-js-app-with-node |
| createdAt | 2015-07-05T18:04:33Z |
| language | en |
| preview | Majority of search result about unit testing Angular.js apps is about how to do it by using test frameworks that run the tests in a real browser. Even though it's great to be able to test your code in multiple platforms, in my opinion it creates a lot of boilerplate code and makes it hard to run the tests in, for instance a CI-server. |
Lean unit tests with minimal setup
As all objects must be Serializable to be used as part of RDD operations in Spark, it can be difficult to work with libraries which do not implement these featuers.
For simple classes, it is easiest to make a wrapper interface that extends Serializable. This means that even though UnserializableObject cannot be serialized we can pass in the following object without any issue
public interface UnserializableWrapper extends Serializable {
public UnserializableObject create(String parm1, String parm2);
| #!/bin/sh | |
| set -e | |
| set -x | |
| for package in $(npm -g outdated --parseable --depth=0 | cut -d: -f3) | |
| do | |
| npm -g install "$package" | |
| done |
| package bm | |
| import ( | |
| "testing" | |
| ) | |
| var mb = map[string]bool{ | |
| "alpha": true, | |
| "beta": true, | |
| "gamma": true, |
| App configuration in environment variables: for and against | |
| For (some of these as per the 12 factor principles) | |
| 1) they are are easy to change between deploys without changing any code | |
| 2) unlike config files, there is little chance of them being checked | |
| into the code repo accidentally | |
| 3) unlike custom config files, or other config mechanisms such as Java |
When the directory structure of your Node.js application (not library!) has some depth, you end up with a lot of annoying relative paths in your require calls like:
const Article = require('../../../../app/models/article');Those suck for maintenance and they're ugly.
Each of these commands will run an ad hoc http static server in your current (or specified) directory, available at http://localhost:8000. Use this power wisely.
$ python -m SimpleHTTPServer 8000