tktk
tktk
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
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
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
These snippets are based on various various AWS documents, blogs, etc, but have been revised for clarity and consistency, and to incorprate modern best practices.
// 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.