Skip to content

Instantly share code, notes, and snippets.

More snippets

Access Logs

The included SQL and CloudFormation YAML snippets create AWS Glue tables for access logs from Application Load Balancers, which can be queried using Amazon Athena. The snippets are intended to be equivalent.

The tables that are created utilize partition projections, which allows for efficient, cost-effective querying of the log data in Amazon S3, without the need to manual create new partitions. Instead, the partitions are created based on the filesnames of the log files. Using the year, month, and day port

More snippets

Organization Trail Logs

Organization trails are a mechanism for capturing AWS CloudTrail logs across entire AWS Organizations. They are similar to standard CloudTrail logs, but have a slightly different file organization structure in S3, which affects their table definitions.

The included SQL and CloudFormation YAML snippets create AWS Glue tables for organization trail logs, which can be queried using Amazon Athena. The snippets are intended to be equivalent.

The tables that are created utilize partition projections, which allows for efficient, cost-effective querying of

More snippets

Standard Access Logs

The included SQL and CloudFormation YAML snippets create AWS Glue tables for standard access logs from Amazon CloudFront, which can be queried using Amazon Athena. The snippets are intended to be equivalent.

The tables that are created utilize partition projections, which allows for efficient, cost-effective querying of the log data in Amazon S3, without the need to manual create new partitions. Instead, the partitions are created based on the filesnames of the log files. Using the year, month, and day portions of the filenames, daily partitions are available when querying

@farski
farski / Athena Snippets.md
Last active November 21, 2021 21:49
Athena snippets
// Sample event data for a proxy request
// {
// "resource": "Resource path",
// "path": "Path parameter",
// "httpMethod": "Incoming request's method name"
// "headers": {Incoming request headers}
// "queryStringParameters": {query string parameters }
// "pathParameters": {path parameters}
// "stageVariables": {Applicable stage variables}
// "requestContext": {Request context, including authorizer-returned key-value pairs}
KV_KEY = 'forecast-alert-datapoint'
module.exports = (robot) ->
postWeatherAlert = (json, callback) ->
postMessage = callback
now = new Date()
# This function posts an alert about the current forecast data always. It
# doesn't determine if the alert should be posted.
### Keybase proof
I hereby claim:
* I am farski on github.
* I am farski (https://keybase.io/farski) on keybase.
* I have a public key whose fingerprint is 7AEC 5570 3246 6AB1 0FA0 5856 FD44 A722 1846 81BC
To claim this, I am signing this object:

Generally my configuration plan looks something like this:

  • A root .xcconfig file called Common.xcconfig. This includes nearly all of buid settings, app configuration, etc
  • A Development.xcconfig file that overrides a few things like ONLY_ACTIVE_ARCH (inherts from Common)
  • Debug.xcconfig (inherits from Development)
  • Beta.xcconfig (inherits from Development)
  • Release.xcconfig (inherits from Common)

I make sure to have an xcconfig for each Build Configuration I have set up for the project. That makes it really easy to do things like define specific icons for different build types, and obviously all the other normal build flags you would need.