farski

More snippets

Flow Logs

tktk

farski

tktk

farski

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

farski

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

farski

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 are not partitioned, as the native filenames of CloudFront access logs are not compatible with Athena partition projections. The speed and cost of querying these tables will depend on how much data is in the S3 bucket location it's anlyzing. If the bucket is configured to expire data after several days, using an unpartitioned table may be acceptable. If your bucket conta

farski

Snippets

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.

• Amazon CloudFront
• Application Load Balancers
• AWS CloudTrail
• Amazon S3
• Amazon VPC

farski

// 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}

farski

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.

farski

### 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:

farski

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.