When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.
Please note we have a code of conduct, please follow it in all your interactions with the project.
(:identity req) is auth backend independent way to access user data:current-user doesn't imply that authentication is required, route should also have :auth-rules if authentication is required
| defmodule MyApp do | |
| use Application | |
| def start(_type, _args) do | |
| import Supervisor.Spec, warn: false | |
| children = [ | |
| Plug.Adapters.Cowboy.child_spec(:http, MyApp.Router, [], [ | |
| dispatch: dispatch | |
| ]) |
| from sqlalchemy import create_engine | |
| from sqlalchemy.orm import Session | |
| from myapp.models import BaseModel | |
| import pytest | |
| @pytest.fixture(scope="session") | |
| def engine(): | |
| return create_engine("postgresql://localhost/test_database") |
Source: http://www.jejik.com/articles/2007/02/a_simple_unix_linux_daemon_in_python/
by Sander Marechal
I've written a simple Python class for creating daemons on unix/linux systems. It was pieced together for various other examples, mostly corrections to various Python Cookbook articles and a couple of examples posted to the Python mailing lists. It has support for a pidfile to keep track of the process. I hope it's useful to someone.
| #!/bin/bash | |
| # Author: Erik Kristensen | |
| # Email: erik@erikkristensen.com | |
| # License: MIT | |
| # Nagios Usage: check_nrpe!check_docker_container!_container_id_ | |
| # Usage: ./check_docker_container.sh _container_id_ | |
| # | |
| # Depending on your docker configuration, root might be required. If your nrpe user has rights | |
| # to talk to the docker daemon, then root is not required. This is why root privileges are not |
| Three comparison points: | |
| Presto + RCFile vs Impala + RCFile vs Impala + Parquet | |
| Note: Query time, CPU utilization, Disk read tput (KBRead) | |
| Impala v1.1.1 | |
| Presto v0.52 | |
| ================================================================================================================================ | |
| Presto + RCFile: | |
| select ss_sold_date_sk, count(*) from store_sales_rcfile group by 1 order by 1 limit 2000; |
| package test | |
| import scala.reflect.runtime.universe._ | |
| object ReflectionHelpers extends ReflectionHelpers | |
| trait ReflectionHelpers { | |
| protected val classLoaderMirror = runtimeMirror(getClass.getClassLoader) |
One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.
Most workflows make the following compromises:
Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.
Use production SSL certificates locally. This is annoying
