| """ | |
| conda install -c conda-forge postgresql psycopg2 sqlalchemy | |
| initdb -D /tmp/dask_db | |
| postgresql -D /tmp/dask_db | |
| pg_ctl -D /tmp/dask_db -l logfile start | |
| createuser --encrypted --pwprompt dask | |
| createdb --owner=dask dask_db | |
| """ |
| # see also https://github.com/wrobstory/pgshift | |
| import gzip | |
| from io import StringIO, BytesIO | |
| from functools import wraps | |
| import boto | |
| from sqlalchemy import MetaData | |
| from pandas import DataFrame | |
| from pandas.io.sql import SQLTable, pandasSQL_builder |
I have a pet project I work on, every now and then. CNoEvil.
The concept is simple enough.
What if, for a moment, we forgot all the rules we know. That we ignore every good idea, and accept all the terrible ones. That nothing is off limits. Can we turn C into a new language? Can we do what Lisp and Forth let the over-eager programmer do, but in C?
This is a mix between two sources:
basically the first resource is great but didn't work for me: I had to remove the trailing "/*" in the resource string to make it work. I also noticed that setting the policy on the source bucket was sufficient. In the end these are the exact steps I followed to copy data between two buckets on two accounts
Basically the idea there is:
| #!/usr/bin/env python | |
| # vim: set fileencoding=utf8 : | |
| ``` | |
| $ pip install -U boto3 retrying | |
| $ export AWS_DEFAULT_PROFILE=test | |
| $ cat foo.sql | |
| select count(*) | |
| from bar | |
| $ python athena.py foo.sql | |
| $ ls -1 |
Automated analysis is the main advantage to working with a modern statically typed compiled language like C++. Code analysis tools can inform us when we have implemented an operator overload with a non-canonical form, when we should have made a method const, or when the scope of a variable can be reduced.
In short, these tools catch the most commonly agreed best practice mistakes we are making and help educate us to write better code. We will be fully utilizing these tools.
All reasonable warning levels should be enabled. Some warning levels, such as GCC's -Weffc++ warning mode can be too noisy and will not be recommended for normal compilation.
Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.
In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.
Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j
| #!/bin/bash | |
| #do we wanna limit bandwidth? pass argument BW:limit (ie: BW:10) | |
| if [[ "$1" == "BW:"* ]]; then | |
| NEWBW=`echo $1|cut -d: -f2` | |
| if [ "$NEWBW" != "" ]; then | |
| BW="--limit-rate=${NEWBW}k" | |
| echo using bw limit ${NEWBW} | |
| fi | |
| shift |
