Quicksight can automatically connect to databases that can be accessed via a public IP. If your DB is publicly accessible to the Internet (with Security Group filtering of course), then you can pretty much ignore this article.

If you happen to have the weird case where your DB does have a public IP address but it is not actually accessible to the public Internet for policy, technical or historical reasons, then read on.

Quicksight VPC Connection Requirements

Quicksight has the option of creating a connection between you instance of Quicksight and one of your VPCs. It does that by injecting a Network Interface into a subnet you specify from the target VPC.

You only have to supply the

• VPC ID that your target DB is in.
• Subnet that is routable to the subnet your target DB is in
• Security Group dedicated to the Quicksight connection that will allow all TCP taffic to the target DB
• Optionally a DNS Inbound Endpoint

We’re going to assume that the target DB and its VPC already exists.

You can use an existing Subnet as long as its in the same VPC and is routable to the subnets used by the target DB. By default subnets in a VPC can route to any other subnet in the VPC, but you should double check.

When you create the VPC Connection in the Quicksight management console, it will automatically create a Network Interface on the specified Subnet and will be associated with the Security Group specified.

Note that the Security Group associated with this new Quicksight Network Interface will be stateless. Any response packets coming back from a Quicksight request will have randomly allocated port numbers. Normally Security groups are stateful and handle this for you. But in the case of the Quicksight Network Interface you have to explicitly enable that any port is allowed for inbound.

The optional DNS Inbound Endpoint allows you to tell Quicksight to use the private DNS Resolver for your VPC instead of querying just the Public DNS zones. This is what is needed if your target DB has a Public IP address. Without this setting this Quicksight will get the Public IP address when it queries the Endpoint name of your DB. You will be scratching your head for days wondering why the connection is not working.

If you do use DNS Inbound Endpoint option, you will have to set it up in Route53.

Detailed instructions for all of this are described below.

A VPC Connection will allow Quicksight to connect to any of the following in your VPC:

• Amazon OpenSearch Service
• Amazon Redshift
• Amazon Relational Database Service
• Amazon Aurora
• MariaDB
• Microsoft SQL Server
• MySQL
• Oracle
• PostgreSQL
• Presto
• Snowflake

You can reuse a VPC Connection for any Datasource in your Quicksight account in a region.

Subnet Info

Get VPC Info

We’ll need the VPC ID and the CIDR Block associated

You can look at your RDS Configuration to see what VPC it is in.

In this example:

• VPC ID ends in 2aed
• CIDR Block: 10.0.0.0/16
  

Pick a Subnet for the Quicksight Network Interface to Use

The criteria are:

• In the same VPC as the target DB
• Is a private subnet
• In the same Availability Zone as at least one of the subnets associated with the target DB
• Routable to that subnet in the target DB
  • Has a route table that routes to the VPC CIDR Block
  • And the Target DB Subnets also can route to the VPC CIDR Block
• Doesnt have an ACL that would block acces to/from the target DB
  • This is the usual case

Find the subnets used on the target DB

In this example our target DB is an Aurora Postgres cluster. Looking at the RDS Console we can find the subnets its usings

Click on one of the subnets to view the subnet info

See what Availability Zone its in (us-east-1b in this example)

Confirm it routes to the VPC CIDR Block (10.0.0.0/16 in this example)

• Go to the subnet view in the VPC Console.
• Find an existing subnet that also routes to the same VPC CIDR Block (or overlapping subset with the DB subnet and its on the same Availability Zone)
  • You could also create a new subnet for this as long as it meets the same criteria
• In our example its the subnet that ends with 90dc

Security Group

Create a new Security Group dedicated to the Quicksight Network Interface. You don’t have to create one specific to this, but it will make management easier than trying to mix it in with your existing Security Groups.

We’ll call it Amazon-QuickSight-access. Nothing magic about the name though, whatever fits into your naming scheme.

Inbound Rules

Set the Inbound Rules to allow trafic on all TCP ports. As mentioned earlier, this is because this will be a stateless security group and all response packets will have random inbound ports.

Outbound Rules

The Outbound Rules should limit the destinations to just your target DB. The easiest way is to set the destination to be the Security Group set in your RDS Database.

You should also limit the outbound ports to be ones appropriate for your target DB, such as port 5432 for Postgres.

We ran into a problem where for historical reasons, there were some existing inbound rules in the Target DB that prevented us from using the Target DB as the destination security group, so we used a CIDR range that covered the Target DB range of addresses. This should be an unusual situation and you can probably ignore it.

DNS Resolver Endpoints (optional)

You only need to fill this in for cases where the DNS lookup of your Target DB Endpoint would be incorrect against Public DNS. The usual use case for this is when you have a somewhat complicated VPC Peering setup where your Target DB is on the other side of a VPC Peering setup. In that case, only the DNS Resolver in your private VPC may know the proper resolution of the Target DB Endpoint.

In our case, we had the unusal situation that our Target DB had a public IP address, so when Quicksight would do a DNS Query on the Target DB Endpoint name, it would get the Public IP address which was not valid for the VPC Connection. The workaround is for Quicksight to use the local VPC DNS Resolver. And thus our need to setup the DNS Resovler Endpoints

It took a while to figure out this was why we could never get the VPC Connection to work until we set this up. The diagnostics of the VPC Connection Validation check does not differentiate between Networking, DNS, or username/password problems. An issue in anyone of those can make the connection validation fail.

Route53 Resolver Inbound Endpoints

Create a Security Group for the Resolver

The resolver needs to have a security group for itself to allow the DNS requests to get to it.

Inbound Rules

• Create a new Security Group and call it something like quicksight-route53-resolver or whatever fits your nameing scheme.
• Set the Inbound Rules to allow for DNS UDP and DNS TCP from all sources on the VPC CIDR Block

Outbound Rules

Can leave the default outbound to all rule

Setup the Route53 Endpoint Resolver

You will need to go to the Route53 Console and select Resolver->Inbound endpoints and click on the Create Inbound Endpoint button.

• Set the Endpoint name
  • Something that fits your naming scheme
  • Our example is quicksight-prod
• Set the VPC ID to be the same as your VPC-ID used for your Target DB
• Set the Security Group to the Security Group you created
• Set the Availability Zone / Subnet for two IP Addresses for the resolver
  • Could be any that are routable to the Subnet that is assigned to the VPC Connection.
  • Should be a private subnet
  • Might as well make one of them the same Subnet used by the VPC Connection
  • Check the option Use an IP address that is selected automatically for both
  • Click Submit when done

You will then end up with an Inbound Endpoint that will have been assigned two IP addresses. These addresses will be needed to supply to the VPC Connection and be used to update the Quicksight Security Group.

In this example the two IP Addresses are

• 10.0.100.120
• 10.0.101.80

Update the Quicksight Security Group for DNS

If you are using the DNS Resolver Inbound Endpoints feature, you will also have to update the Outbound Rules of the Security Group we created earlier for the Quicksight Network Interface. This is to enable Quicksight to be able to access the DNS Resolver as well as the Target DB.

To do this we will add DNS UDP and DNS TCP to the Output Rules of the Amazon-QuickSight-access Security Group for each of the two IP Addresses from the Inbound Resolver we just created. Note that you need to have the CIDR suffix /32 at the end when entering them into the Security Group editor.

Create the Actual VPC Connection

Now we have everything we need to setup the actual VPC Connection in the Quicksight management console.

You will of course need to have proper permissions to access and manage Quicksight in your account. That is beyond the scope of this article. We’re going to assume you have all that already.

• Enter the Quicksight Console, click on your username on the topr right of the page and select Manage Quicksight

• Then select Manage VPC Connections in the left hand Navbar

• Click on Add VPC Connection to create the new connection

Fill in the form with the info we found or created earlier:

• VPC Connection Name
  • Appropriate name of the connection based on your naming conventions
  • Our example: my-aurora-db
• VPC ID: The VPC ID we have been using earlier
  • Our example ends with 2aed
• Subnet ID: The Subnet we chose for the Quicksight Network Interface
  • In our example it ends with 90dc
• Security Group ID: The Security Group we created for Quicksight
  • Our example: Amazon-QuickSight-access (ended in 16e8)
• DNS Resolver Endpoints: The IP addresses from the DNS Resolver Inbound Endpoints
  • Our example: 10.0.100.120 and 10.0.101.80

Create a Dataset using the VPC Connection

Now that the VPC Connection has been setup, we can use it to create a Dataset from the Target DB.

• Click on the Quicksight logo on the top left of the screen to get back to the Quicksight home page.
• Click on Datasets at the bottom of the left Navbar
• Click on New dataset on the top right of the page.

• Click on Aurora (or other source, but we’re not going to show other sources in this article)

Fill in the New Aurora data source form

• Data source name: Our example is my-data-source
• Connection type: Select the VPC connection we created
  • my-aurora-db
    
• Database connector: PostgreSQL
• Database server: The Endpoint of your Aurora DB
  • This is the fully qualified DNS name of your DB endpoint
  • You can find it in the Connectivity & security tab on the DB’s RDS Console page
  • You probably want to use a reader endpoint
• Port: The proper port for your Target DB
  • Postgres default is 5432
• Database Name: The name of the database within the RDS of interest
  • Same name you would use in a DB connection or in psql to connect to your working DB’s
• Username: The db username needed to connect
• Password: The db password

Click on Validate Connection

It should turn to Validated with a checkmark if all went well. Should happen within a few seconds.

At this point you can now click on the Create data source button and do the normal Quicksight data source stuff. That is all independent of the VPC Connection and is not part of this article.

If the VPC Connection fails to Validate

If the Validate failed you are going to have to check several things. There will be an error message. You can click on the details link, but its probably not going to be helpful.

The error diagnosicts for the VPC Connection rarely gives you any more info other than it could not connect to the DB.

You need to determine if its because of:

• The routing from the Quicksight Network Interface to the Target DB
• The Security Group settings
• Basic error in the regular connection parameters (Database name, Username, Password)
• The Database Server is the correct value and Quicksight DNS query is getting the right value (private IPs not public or nothing at all)

Check for basic connectivity

You can check the basic connectivity (routing and security groups) is working using the Reachability Analyzer in the VPC Console. Unfortunately the analyzer has a limited set of elements that can be specified as a Source and Destination. The only one that applies to the Quicksight VPC Connection as a source and Aurora RDS as a Destination are Network Interfaces. So we’re going to need to find the IDs of those two Network Interfaces.

Find the ID of the VPC Connection Network Interface

You will need to know the Network Interface ID of the interface created for the VPC Connection. To figure that out go to the EC2 Console page and click on Network Interfaces under Network & Security in the Navbar on the left

Then search for the name you used for the Quicksight connection. Our example was my-aurora-db It will be part of the description of the Network Interface associated with that connection. In our example it starts with eni-0b9e

Find the ID of the Target DB Network Interface

You will need to know any of the Network Interface IDs of the Target DB. There can be a few as there may be one per Availability Zone. It doesn’t matter which one you choose.

• Still on the EC2 Console page Network Interfaces page, search for the Target DB’s Security Group name.
  • You can find the Target DB Security Group name on the RDS Console page for your Target DB under the Connectivty & Security tab labeled VPC security groups
• Select any one of them.
  • Our example starts with: eni-050d

Run the Reachability Analyzer

Go to the VPC Console and click on the Create and analyze path button on the top right of the page

• Give it a name
• Select Network Interfaces for the Source type and Destination type
• Specify the Network Interface ID of the Quicksight Network Interface we found
  • Starts with eni-0b9e in our example
• Specify the Network Interface ID of the Target DB Network Interface we found
  • Starts with eni-050d in our example
• Specify 5432 for the Destination port
  • Or whatever port you set for your Target DB if not Postgres
• Protcol is TCP

• Click on Create and analyze path

If it all works you should see:

If that works, you configured the DNS Endpoint Resolver, but your VPC Connection / Dataset creation still doesn’t work, you may want to repeat the Reachability Analyzer test for the DNS TCP and UDP ports in addition to the Postgres Port to double check for the DNS passing properly between the resolver and Quicksight.

Conclusion

If the Reachability Analyzer said connectivity is ok and it still doesn’t work, then its probable that one of the other basic connection parameters is wrong, or there is something wrong with the Endpoint name. If you hadn’t tried setting up the DNS Endpoint Resolver option, you can try that to see if there was a problem with how Quicksight was resolving the DNS for your Endpoint. That was what started this whole journey for me.

Otherwise, hopefully this did work for you and you can now happly view your Target DB in Quicksight!

The post Connect Quicksight to RDS in a private VPC first appeared on Cognizant Transmutation.

Implements the AWS Tutorial Build a Vacation Rental Site with Amplify Studio but instead of being Javascript based, uses Clojurescript for the project implementation. It does incorporate the Javascript output of Amplify Studio but all code to use it is in Clojurescript.

Tooling Used in the project:

• Create Reagent App to create the project scaffold
• Clojurescript (The whole point of this article!)
• Shadow-CLJS as the build tool / compiler
• Webpack Key to preping JSX and JS Files from Amplify Studio and UI Components to be used with shadlow-cljs transpiled clojurescript.
• Babel Used by webpack to convert JSX to JS
• Reagent (CLJS wrapper around React) for building your user interface
• Amplify Studio and all the related AWS Amplify tooling
• Figma AWS Amplify UI Kit

Prerequisites

Setup an Amplify Studio Project

All the initial setup of the Amplify Studio Project on AWS and the associated Figma project is already described in the first part of the excellent Build a Vacation Rental Site with Amplify Studio so will not repeat it here.

That first part of the article will have you do all the following in the appropriate Web Consoles and services AWS and Figma). You won’t be doing any CLI commands on your local dev computer:

• Setup an Amplify Studio project via the Amplify Sandbox
• Create a basic data model in Amplify Studio
• Deploy the start of the Amplify project to AWS
• Create some sample data
• Set up a Figma project using the Amplify UI Components and shows you how to modify it
• Import the modified Figma project into the Amplify project
• Link the data model and the UI Component in Amplify Studio
• Create a collection view using Amplify Studio

Start by following the instructions from the original article, Build a Vacation Rental Site with Amplify Studio, up thru to the section: Pull to Studio

Once you have completed that, come back to here and follow the rest of this post at this point.

Creating an Amplify Studio App with Clojurescript

This is the actual instructions on how to create your Amplify Studio app in Clojurescript instead of Javascript. It replaces the remainder all the content after Pull to Studio from the original article Build a Vacation Rental Site with Amplify Studio.

Create a git repo with shadow-cljs / reagent scaffolding

Instead of using create-react-app that would have created a Javascript/React app, we’re going to use create-reagent-app to create the scaffolding of a shadow-cljs / reagent / react app repo.

In this tutorial, we will make this a git repo and snapshot the state at every stage so that if you make a mistake you can go back to an earlier step.

npx create-reagent-app  amplifystudio-cljs-tutorial
cd amplifystudio-cljs-tutorial
git init
git add -A
git commit -m "Initial Commit after create-reagent-app"
npm-install

Add webpack and related dependencies

Shadow-cljs can not directly consume JSX files that are the output of the Figma plugin and it needs some help to incorporate the AWS UI Components files that Amplify Studio injects into the project.

The use of Babel to prepare JSX files for Shadow-cljs is based on info from Shadow CLJS User’s Guide – JavaScript Dialects. This tutorial moves the babel management into webpack configuration as described later on.

The following dependencies are needed primarily to install webpack and its dependencies.

html-webpack-plugin and html-beautifier-webpack-plugin are used to inject the proper JS include for the output of webpack into the index.html.

npm i -D @babel/cli @babel/core @babel/preset-react @babel/preset-env babel-loader html-webpack-plugin html-beautifier-webpack-plugin process webpack webpack-cli

Then update any dependencies to the latest versions
If you don’t already have it, install npm-check-updates

npm install -g npm-check-updates

And then run it to update any dependencies to the latest versions ignoring specified versions in the package.json.

I like to start projects with the latest versions of everything. But you could just make sure shadow-cljs is the latest version, best to stay latest with that.

If you run it without the -u it will just show you what it would update and you could manually update the ones you care about.

ncu -u
npm install

Update your local git repo

git add -A
git commit -m "Snapshot after adding webpack dependencies"

If you want, you could push it to your own remote Github or other repository

Add AWS Dependencies

• AWS Account
  • If you don’t already have an AWS account, you’ll need to create one in order to follow the steps outlined in this tutorial. Create an AWS Account
• Amplify CLI
  If you don’t already have the Amplify CLI installed you can install it with

npm install -g @aws-amplify/cli

• Configure Account / IAM / CLI to work with Amplify
  If you already have an AWS account you want to use and you have things setup in your workstation / Terminal to use AWS CLI via profiles in ~/.aws/credentials, you can just set your profile in your terminal for the profile to use

export AWS_PROFILE=<your profile>

and you don’t need to do amplify configure.

If you haven’t set up aws amplify on your local dev machine before, follow the instructions at Configure the Amplify CLI

Install the aws-amplify libraries in your project

Still at the top of the amplifystudio-cljs-tutorial repo, install the libraries

npm i aws-amplify @aws-amplify/ui-react

You might want to commit the changes to git just as a snapshot in case the next step messes anything up.

git commit -a -m "After adding amplify deps"

Sync repo with Amplify project

Using the amplify CLI, pull the project info and ui-components into your repo.

You’ll get the command to do this from your Amplify Apps page that was created earlier.

If you are using an AWS account via IAM, you should log in to your AWS Console on your default browser. The following command is going to open up your default browser to authenticate to AWS.

If you are not using AWS IAM for auth, but are using the Amplify Console that has its own username/password style login, you don’t need to do anything in advance.

DON’T TYPE THIS EXACT LINE
Use the line from your environment as it has the appID for your application
The following line is just an example

amplify pull --appId dgt42342sdv765la --envName staging

This will eventually open a browser page to authenticate the process. As mentioned earlier, if you are using IAM for access, its easiest if you logged into the AWS Console with your browser first. If you forget to do this, you can still login now, and copy and past the link shown in the output of the CLI command and it will retry authenticating.

If you are using the Amplify Studio username/password, you will get that dialog on the browser and you can fill it in and click Yes

It will then prompt you for a bunch of things to set up your amplify project in this repo

Opening link: https://us-west-2.admin.amplifyapp.com/admin/dgt42342sdv765la/staging/verify/
✔ Successfully received Amplify Studio tokens.
Amplify AppID found: dgtkqevv765la. Amplify App name is: rental-cljs
Backend environment staging found in Amplify Console app: rental-cljs
? Choose your default editor:
  Android Studio
  Xcode (Mac OS only)
  Atom Editor
  Sublime Text
  IntelliJ IDEA
  Vim (via Terminal, Mac OS only)
❯ Emacs (via Terminal, Mac OS only)
(Move up and down to reveal more choices)

Of course the only choice that makes sense is Emacs
(Note even though it says via terminal, it works fine with GUI Emacs)

? Choose the type of app that you're building (Use arrow keys)
  android
  flutter
  ios
❯ javascript

Keep javascript

? What javascript framework are you using (Use arrow keys)
  angular
  ember
  ionic
❯ react
  react-native
  vue
  none

Keep react

? Source Directory Path:  src/amplify
? Distribution Directory Path: public
? Build Command:  npm run-script build
? Start Command: npm run-script start

Enter src/amplifyfor Source Directory Path
Enter public for Distribution Directory Path
This build puts everything in public but other scaffolding or cljs projects may use some other path. It should be the same as the directory above js in the output-dir parameter in shadow-cljs.edn

You can keep the defaults for Build Command and Start Command

The rest of the config inputs and outputs:

✔ Synced UI components.
GraphQL schema compiled successfully.

Edit your schema at /Users/rberger/work/aws/amplifystudio-cljs-tutorial/amplify/backend/api/rentalcljs/schema.graphql or place .graphql files in a directory at /Users/rberger/work/aws/amplifystudio-cljs-tutorial/amplify/backend/api/rentalcljs/schema
Successfully generated models. Generated models can be found in /Users/rberger/work/aws/amplifystudio-cljs-tutorial/src/main
? Do you plan on modifying this backend? (Y/n) Y

Say Y for Do you plan on modifying this backend?

You might want to checkpoint your git repo again after this.

git add -A
git commit -m "After pulling Amplify Studio project"

You can make sure the basic reagent setup is still working by doing:

npm start

The first time you run this, it will take a while to download all the Clojurescript / Clojure dependencies.

And see that the app is running at http://localhost:3000
You will just see Create Reagent App on the page as a header.

Update to support mixing webpack with shadow-cljs

Based on David Vujic’s work Agile & Coding: Hey Webpack, Hey ClojureScript we’re going to add mechanisms to build the javascript code using webpack and the clojurescript code with shadow-cljs. This is necessary when using more recent versions of the AWS Amplify libraries.

Make sure Shadow-cljs dependencies are up to date

In shadow-cljs.edn make sure that the dependencies are up to date (you can check for the latest versions at Clojars)

 :dependencies
 [[reagent            "1.1.0"]
  [binaryage/devtools "1.0.4"]]

Shadow-cljs js-options

Add the following lines to shadow-cljs.edn between the :asset-path and :modules stanzas in the :app section as per Thomas Heller‘s article
How about webpack now?

   :js-options {:js-provider    :external
                :external-index "target/index.js"}

Make a template from index.html

Webpack will be used to update index.html with the proper script include that points to the webpack bundle.

Move public/index.html to public/index.html.tmpl

mv public/index.html public/index.html.tmpl

Edit public/index.html.tmpl

• Add defer to the main script tag

Change:

<script src="/js/main.js"></script>

To:

<script defer src="/js/main.js"></script>

Add in a sytlesheet for the fonts

• Add the following line after the other link tags in <head>

<link
  rel="stylesheet"
  href="https://fonts.googleapis.com/css?family=Inter:slnt,wght@-10..0,100..900&display=swap"
/>

Copy the Amplify CSS to public

Note that the source is styles.css (plural) and the destination is style.css (singular)

cp node_modules/@aws-amplify/ui/dist/styles.css public/css/style.css

Update the scaffold Clojurescript code to support Amplify

Here’s where we actually get to the actually writing of some code to use the Amplify UI Components in an App.

Edit src/main/amplifystudio_cljs_tutorial/app/core.cljs with the following changes

Add the dependencies for the require

Add the aws amplify and ui imports to the require so it looks like:

Note that the amplify pull will populate src/amplify/ui-components and the webpack execution described further on, will set things up so the "ui-components/CardACollection" require can be fulfilled.

(ns amplifystudio-cljs-tutorial.app.core
  (:require [reagent.dom :as rdom]
            ["/aws-exports" :default ^js aws-exports]
            ["aws-amplify" :refer [Amplify] :as amplify]
            ["@aws-amplify/ui-react" :refer [AmplifyProvider]]
            ["ui-components/RentalCollection" :default RentalCollection]))

Update the app function

This is the actual initial page code that is run by the render function. It is primarily hiccup syntax.

Hiccup describes HTML elements and user-defined components as a nested ClojureScript vector.

• The first element is either a keyword or a symbol
  • If it is a keyword, the element is an HTML element where (name keyword) is the tag of the HTML element.
  • If it is a symbol, reagent will treat the vector as a component, as described in the next section.
• If the second element is a map, it represents the attributes to the element. The attribute map may be omitted.
• Any additional elements must either be Hiccup vectors representing child nodes or string literals representing child text nodes.

This code:

• Displays an h1 header
• Wraps the RentalCollection we created in Figma / ui-components with the AmplifyProvider

The :> is a function, adapt-react-class, that tells hiccup/reagent to interpret the next symbol as a React Component.
More info at: React Features in Reagent

The app function:

(defn app []
  [:> AmplifyProvider
  [:h1 "Amplify Studio Tutorial"]
   [:> RentalCollection]])

For comparison here is the equivalent Javascript:

function App() {
  return (
    <AmplifyProvider>
      <RentalCollection />
    </AmplifyProvider>
  );
}

Update the main function

This function is the first code called in the program. It is where you would put any initialization code and then it calls the render function that kicks of the reagent/react event loop.

• Add a bit of logging so we can see that we’re hitting the code at runtime
• Add the Amplify initialization code.

(defn ^:export main []
  (js/console.log "main top")
  (-> Amplify (.configure aws-exports))
  (render))

In the Clojurescript statement:

(-> Amplify (.configure aws-exports))

-> is the thread-first macro. In this case it means that Amplify will be passed in as the second argument of the following form. I.E. its the equivalent to this Clojurescript statement:

(.configure Amplify aws-exports)

In ether case, it is the Javascript interop equivalent to:

Amplify.configure(config);

Setup Webpack / Babel

Babel config file

Babel does the work of converting JSX files to Javascript files suitable for consumption by webpack and shadow-cljs. It is called by webpack.

Create the file .babelrc in the top level of the repo with the content:

{
  "presets": ["@babel/preset-env", "@babel/preset-react"]
}

This tells babel to run the presets:

@babel/preset-env is a smart preset that allows you to use the latest JavaScript without needing to micromanage which syntax transforms (and optionally, browser polyfills) are needed by your target environment(s). This both makes your life easier and JavaScript bundles smaller!

and

@babel/preset-react loads the following plugins:

@babel/plugin-syntax-jsx – enables parsing of JSX
@babel/plugin-transform-react-jsx – transform JSX to Javascript
@babel/plugin-transform-react-display-name – Set displayName in the Javascript

And with the development option Classic runtime adds:

@babel/plugin-transform-react-jsx-self – sets self in the transformed code
@babel/plugin-transform-react-jsx-source – injects the source information (file, lineno) into the the Javascript

Webpack configuration file

Webpack:

At its core, webpack is a static module bundler for modern JavaScript applications. When webpack processes your application, it internally builds a dependency graph from one or more entry points and then combines every module your project needs into one or more bundles, which are static assets to serve your content from.

We are using it to convert the JSX ui-component files from Figma/Amplify Studio into vanilla Javascript via babel.

Webpack is also being used to bundle the src/amplify/models and src/amplify/ui-components directories/files that are pulled from amplify into the repo as modules so that their objects can be imported into the app. This is configured in the resolve block below.

This will be a webpack configuration file, webpack.config.js in the top level of the repo. The following will describe the elements we’re going to use in that file.

Requires

The following requires the webpack modules and plugins used

const path = require("path");
const webpack = require("webpack");
const HtmlWebpackPlugin = require("html-webpack-plugin");
const HtmlBeautifierPlugin = require("html-beautifier-webpack-plugin");

Basic Webpack config

• Set mode to development
• entry – The file generated by shadow-cljs describing all the require/imports seen in the code
• output – Where webpack should put its final bundle of javascript that will be included by a <script> tag in the index.html
• devtool – Tells webpack to generate source maps to be consumed by the browser devtools

module.exports = {
  mode: "development",
  entry: "./target/index.js",
  output: {
    path: path.resolve(__dirname, "public"),
    filename: "js/libs/bundle.js",
    clean: false,
  },
  devtool: "source-map",

Rules

This is the main directives that tell weback what to do.

• test: /.m?js/, – Regex that specifies what file types to apply to the first rule to (ones that end with .mjs or .js)
  • fullySpecified: false – the import / require statements should not end with file suffixes
  • alias – Maps the path to the javascript files to a module name. This allows the code to require the Amplify Studio models and ui-components as importable modules.
• test: /.jsx$/ – Regex that specifies which file types to apply to the second rule (JSX files)
  • exclude – Don’t apply it to files installed by npm in /node_modules/
  • use – Apply babel to the JSX files. The .babelrc file specified earlier tells babel to transform the JSX files to vanilla javascript

    rules: [
      {
        // docs: https://webpack.js.org/configuration/module/#resolvefullyspecified
        test: /.m?js/,
        resolve: {
          fullySpecified: false,
          alias: {
            models: "../src/amplify/models/index.js",
            "ui-components": "../src/amplify/ui-components",
          },
        },
      },
      {
        test: /.jsx$/,
        exclude: /node_modules/,
        use: ["babel-loader"],
      },
    ],

Plugins

This is where plugins are loaded.

• process – This was needed as webpack 5 no longer includes a polyfil for the process Node.js variable. There were some dependencies that required process.env
• HtmlWebpackPlugin – Enables creating public/index.html from a temlate so that webpack can inject the path to its bundle into the index.html. Also useful if you want to automate the updates of the index.html for other things.
• HtmlBeautifierPlugin Cleans up the index.html with proper newlines mainly

  plugins: [
    new webpack.ProvidePlugin({
      process: "process/browser",
    }),
    new HtmlWebpackPlugin({
      template: "./public/index.html.tmpl",
      filename: "index.html",
    }),
    new HtmlBeautifierPlugin(),
  ],

The Html plugins / index.html templating are not totally necessary. You could just add your own script tag to index.html instead such as:

<script defer src="js/libs/bundle.js"></script>

The full webpack.config.js

Create a file webpack.config.js also at the top level of the repo with the content:

const path = require("path");
const webpack = require("webpack");
const HtmlWebpackPlugin = require("html-webpack-plugin");
const HtmlBeautifierPlugin = require("html-beautifier-webpack-plugin");

module.exports = {
  mode: "development",
  entry: "./target/index.js",
  output: {
    path: path.resolve(__dirname, "public"),
    filename: "js/libs/bundle.js",
    clean: false,
  },
  devtool: "source-map",
  module: {
    rules: [
      {
        // docs: https://webpack.js.org/configuration/module/#resolvefullyspecified
        test: /.m?js/,
        resolve: {
          fullySpecified: false,
          alias: {
            models: "../src/amplify/models/index.js",
            "ui-components": "../src/amplify/ui-components",
          },
        },
      },
      {
        test: /.jsx$/,
        exclude: /node_modules/,
        use: ["babel-loader"],
      },
    ],
  },
  resolve: {
    extensions: ["", ".js", ".jsx"],
  },
  plugins: [
    new webpack.ProvidePlugin({
      process: "process/browser",
    }),
    new HtmlWebpackPlugin({
      template: "./public/index.html.tmpl",
      filename: "index.html",
    }),
    new HtmlBeautifierPlugin(),
  ],
};

Add a script to run webpack

Add the following line to the ”scripts” section of package.json. It will allow you to run a that will update the bundle automatically when you change any of the amplify files or when shadow-cljs updates the target/index.js

    "pack": "webpack --watch"

Update git

Update .gitignore

add the following to .gitignore

/target/

Add all the new files to the commit

git add -A
git commit -m “Sync up all the final changes”

Running the development service locally

Start the shadow-cljs watch process. (shadow-cljs watch app) using the npm command:

npm start

And in another terminal window, also at the top of the repo run the webpack watch process:

npm run pack

Should see something like the following. The images and values are dependent on how you set up the data when following along with the first part of the Build a Vacation Rental Site with Amplify Studio.

Troubleshooting

If when you start the shadow-cljs process, npm start, and you get something like:

...
shadow-cljs - watching build :app
[:app] Configuring build.
[:app] Compiling ...
[2022-01-02 21:55:15.214 - WARNING] :shadow.cljs.devtools.server.util/handle-ex - {:msg {:type :start-autobuild}}
AssertionError Assert failed: (map? rc)
...

The js-provider :external config in shadow-cljs.edn is masking the actual error. In order to see what the error is, comment out the :js-options block in shadow-cljs.edn like:

:builds
 {:app
  {:target     :browser
   :output-dir "public/js"
   :asset-path "/js"
   ;; :js-options {:js-provider    :external
   ;;              :external-index "target/index.js"}
   :modules    {:main
                {:init-fn amplifystudio-cljs-tutorial.app.core/main}}}

and then run npm start again and see what the error is. Correct the error and then remember to uncomment the :js-options block.

Completing the Tutorial with Amplify UI Overrides

We pick back up the original tutorial at the Use a Prop section to show how the UI Components can be customized just with Component Props and runtime Overrides.

Overrides are a powerful feature that are builtin to the Amplify UI Components and allow you to inject attributes into the children of components at runtime. It makes the Amplify UI Components very flexible without having to modify the actual code of the components. This allows you to update the Figma design aspects and still update your local copy of the ui-components with an amplify pull since you don’t make local changes to that code.

Use a Prop

You can customize these React components in your own code. First, you can use props in order to modify your components. If you wanted to make your grid of rentals into a list, for example, you could pass the prop type=”list” to your RentalCollection.

In Javascript you would say:

<RentalCollection type="list" />

and in Clojurescript:

[:> RentalCollection {:type "list"}]

And that will make the view go from a grid to a list:

The props are listed for each component type at Amplify UI Connected Components

Use an Override

Overrides allow you to inject props into the children of a component.

In our example RentalCollection, the images in the child cards are kind of squashed. To fix that we want to set the objectFit prop of the image element of the card to cover.

In Javascript you would use:

<RentalCollection
  type="list"
  overrides={{
    "Collection.CardA[0]": {
      overrides: {
        "Flex.Image[0]": { objectFit: "cover" },
      },
    },
  }}
/>

In Clojurescript we use:

[:> RentalCollection {:type "list"
                      :overrides {"Collection.CardA[0]"
                                  {:overrides {"Flex.Image[0]"
                                               {:object-fit "cover"}}}}}]])

Now the images are no longer squished:

Themes and Conclusion

That completes showing the differences of using Clojurescript instead of Javascript with Amplify Studio and Amplify UI Connected Components.

You can refer back to the original AWS Tutorial Build a Vacation Rental Site with Amplify Studio for the remaining content on how to use the AWS Amplify Theme Editor in Figma to add a theme to the UI Components. This should work without having to change any of your Clojurescript code as you modify the Ui component code that you load via amplify pull via Figma.

It is also possible to apply themes directly in your code. Doing that with Clojurescript will be left to a possible future article.

The full project / code for this repo is at https://github.com/rberger/amplifystudio-cljs-tutorial.

Feel free to post issues or questions there.

The post Use Amplify Studio Figma Connector with Clojurescript first appeared on Cognizant Transmutation.

While developing clojurescript web apps, you may require that the development http server (shadow-cljs)[https://github.com/thheller/shadow-cljs] operate with SSL/TLS to serve up HTTPS, not just HTTP.

This is particuarly true if you need to test things out on an iPhone or Android phone but still run with the development server so you can iterated changes just as quick as when you are working with desktop clients.

Its a bit tricky to get everything lined up to make SSL/TLS work locally as Apple (and I presume other browsers) no longer support self-signed certificates for HTTPS servers. So you need a private CA and a certificate generated from the private CA.

This is a guide to set up:

• A Private Certificate Authority (CA)
• A Server Certificate for your shadow-cljs development server
• How to configure shadow-cljs.edn for SSL
• How to install the CA Root Certificate on other clients (like an iPhone) so they can access the shadow-cljs servers

NOTE: This server / CA / Certificates should never be used in production or in any particularly public way. It’s not secure. We’re doing this to get around the normal browser / server security just for local development.

Install mkcert

See the following for more info or how to install on Linux: GitHub – FiloSottile/mkcert: A simple zero-config tool to make locally trusted development certificates with any names you’d like.

Install mkcert on macOS

> brew install mkcert
> brew install nss # if you use Firefox

Create a local CA to be used by mkcert and clients

> mkcert -install
Created a new local CA 💥
Sudo password:
The local CA is now installed in the system trust store! ⚡
The local CA is now installed in the Firefox trust store (requires browser restart)! 🦊
The local CA is now installed in Java's trust store! ☕

Create a pkcs12 certificate

Easiest to do this in the directory you are running the shadow-cljs project.
Create a subdirectory ssl at the same level as shadow-cljs (top level of the repo usually) and cd into ssl

❯ cd ~/work/my-project
❯ ls
Makefile        RELEASE_TAG     bin             dev             package.json    shadow-cljs.edn test
README.org      amplify         deps.edn        node_modules    resources       src             yarn.lock

❯ mkdir ssl
❯ cd ssl

Create the certificate that the shadow-cljs servers will use as their server certificates. You want to specify all the domains and IPs that would be associated with the certificate and the way you will access the server.
In my case my iMac has two interfaces plus localhost. One interface is the Ethernet, the other is the wifi. And just to be safe, I’m putting in their IPv6 addresses as well.

❯ mkcert -pkcs12 discovery.local localhost  192.168.20.10 192.168.20.11 127.0.0.1 ::1 fd95:cb6f:7955:0:1878:b8b5:1b3b:ad27 fd95:cb6f:7955:0:4cd:c922:d1b3:2eb5

Created a new certificate valid for the following names 📜
 - "discovery.local"
 - "localhost"
 - "192.168.20.10"
 - "192.168.20.11"
 - "127.0.0.1"
 - "::1"
 - "fd95:cb6f:7955:0:1878:b8b5:1b3b:ad27"
 - "fd95:cb6f:7955:0:4cd:c922:d1b3:2eb5"

The PKCS#12 bundle is at "./discovery.local+7.p12" ✅

The legacy PKCS#12 encryption password is the often hardcoded default "changeit" ℹ

It will expire on 20 January 2024 🗓

Install the cert into the keystore

NOTE: The passwords you use here should not be used anywhere else, particularly on public services. They do not have to be super secret, great passwords as they will be in the clear in your shadow-cljs.

You will create a local Java JKS Keystore in ssl to be used by shadow-cljs servers

• Destination Password: This will be the password specified in shadow-cljs.edn to gain access to the keystore. Our example will be super-secret
• Source keystore password: The password that mkcert used to generate the Server Certificate and thus the password of the Server Certificate. I could not find a way to specify it. It defaults to changeit

  ❯ keytool -importkeystore -destkeystore keystore.jks -srcstoretype PKCS12 -srckeystore discovery.local+7.p12
  Importing keystore discovery.local+7.p12 to keystore.jks...
  Enter destination keystore password: super-secret
  Re-enter new password: super-secret
  Enter source keystore password: changeit
  Entry for alias 1 successfully imported.
  Import command completed:  1 entries successfully imported, 0 entries failed or cancelled

Configure shadow-cljs.edn to enable SSL

Mainly need to add an :ssl coda to the start of the shadow-cljs.edn

{:deps  true
 :nrepl {:port 8777}
 :ssl {:keystore "ssl/keystore.jks"
       :password "retold-fever"}
 :dev-http {8020 {:root "resources/public"}}
 ... rest of your shadow-cljs.edn file...

No need to specify the hostnames. In fact that will limit access to IP addresses that resolve to that name which may be incorrect.
More info on the :ssl configuration at Shadow CLJS User’s Guide: SSL

[Re]start your shadow-cljs watch process and it should say something like the following at some point in its startup where https is the protocol shown for the http and shadow-cljs servers:

...
shadow-cljs - HTTP server available at https://localhost:8020
shadow-cljs - server version: 2.15.8 running at https://localhost:9631
shadow-cljs - nREPL server started on port 8777
shadow-cljs - watching build :app
...

Assuming you set the certificate to support any other domain names and IP addresses associated with your computer running this, they will also work as the host address in your client URL accessing this server. But only if running on the same machine as this server.

If you want to make another device (like an iPhone or another computer) access this server, follow the next steps.

Export the Root CA of your Private CA to other Clients

In order for other machines on your LAN to access the shadow-cljs server running with the Private CA and Server certificate set up in the earlier steps, you will need to export the Root CA from that machine to these other clients.

Find the location of the Root Certificate of the Private CA

When you ran mkcert install it created the root certificates of the Private CA and stashed them somewhere appropriate for your system. You can find out where with the command:

❯ mkcert -CAROOT
/Users/rberger/Library/Application Support/mkcert

❯ ls '/Users/rberger/Library/Application Support/mkcert'
rootCA-key.pem rootCA.pem

You will want to copy the rootCA.pem to other clients that would access the shadow-cljs servers.

For transferring to other Macs or iOS devices

open '/Users/rberger/Library/Application Support/mkcert'

Which will open a finder window with the directory where these pem files are:

And then select AirDrop to send them to other macOS or iOS devices
Otherwise you can email it or send the file some other way to a destination device.

Install the Private CA Root Cert on iOS device

• Once you send the Cert to an iOS device, you will get a message
  
• Select iPhone and then select Close:
  
• Go to Settings and you’ll see the a new option Profile Downloaded Click on that and the go thru the rest of the dialogs agreeing to Install the downloaded profile.

• After completing all the install dialogs, this client should be ready to connect to the shadow-cljs using https.

The post Set up SSL/TLS for shadow-cljs https server first appeared on Cognizant Transmutation.

You have this great Amplify App using AppSync GraphQL. You eventually find that you need to be able to access that data in your AppSync GraphQL database from tools other than your Amplify App. Its easy if you just have your AppSync API protected just by an API Key. But that isn’t great security for your data!

One way to protect your AppSync data is to use Cognito Identity Pools. Amplify makes it pretty transparent if you are using Amplify to build your clients. AppSync lets you do really nice table and record level access control based on logins and roles.

What happens if you want to access that data from something other than an Amplify based client? How do you “login” and get the JWT credentials you need to access your AppSync APIs?

Use AWS CLI

The most general way is to use the AWS CLI to effectively login and retrieve the JWT credentials that can then be passed in the headers of any requests you make to your AppSync APIs.

Unfortunately its not as easy as just having your login and password. It also depends on how you configured your Cognito Identity Pool and its related Client Apps.

Cognito User Pool Client App

You can have multiple Client Apps specified for your Cognito User Pool. I suggest having one dedicated to these external applications. That way you can have custom configuration just for this and not disrupt your main Amplify apps. Also you can easily turn it off if you need too.

In my case I created a new client app shoppabdbe800b-rob-test2 as a way to test a client app with no App Client Secret. This makes it easier to access from the command line as you do not have to generate a Secret Hash (will describe how to deal with that below).

If you want to allow admin level access (ie a user with admin permission) you need to check Enable username password auth for admin APIs for authentication (ALLOW_ADMIN_USER_PASSWORD_AUTH)

If you want to allow regular users to login you must also select Enable username password based authentication (ALLOW_USER_PASSWORD_AUTH)

The defaults for the other fields should be ok. Be sure to save your changes.

Minimal IAM permissions

As far as I can tell, these are the minimal IAM permissions to make the aws cognito-idp command work for admin and regular users of AppSync (replace the Resource arn with the arn of the user pool[s] you want to control):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "cognito-idp:AdminInitiateAuth",
                "cognito-idp:AdminGetUser"
            ],
            "Resource": "arn:aws:cognito-idp:us-east-1:XXXXXXXXXXXXX:userpool/us-east-1_XXXXXXXXX"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
                "cognito-idp:GetUser",
                "cognito-idp:InitiateAuth"
            ],
            "Resource": "*"
        }
    ]
}

Get the Credentials with no App Client Secret

This example is if you did not set the App Client Secret.

You should now be able to get the JWT credentials from the AWS CLI.

This assumes you have set up your ~/.aws/credentials file or whatever is appropriate for your command line environment so that you have the permissions to access this service.

• When using the ADMIN_USER_PASSWORD_AUTH

aws cognito-idp admin-initiate-auth --user-pool-id us-east-1_XXXXXXXXXX --auth-flow ADMIN_USER_PASSWORD_AUTH --client-id XXXXXXXXXXXXX --auth-parameters USERNAME=username1,PASSWORD=XXXXXXXXXXXXX > creds.json

• When using the USER_PASSWORD_AUTH

aws cognito-idp initiate-auth --auth-flow USER_PASSWORD_AUTH --client-id XXXXXXXXXXXXX --auth-parameters USERNAME=username2,PASSWORD=XXXXXXXXXXXX > creds.json

Of course replace the XXXX‘s with the actual values.

• user-pool-id – The pool id found at the top of the User Pool Client Apps page
• client-id – The client-id of the app client you are using
• USERNAME – The Username normally used to login to your Amplify app
• PASSWORD – The Password normally used to login to your Amplify app

The results will be in creds.json. (You could not use the > creds.json if you want to just see the results)

Get the Credentials when there is an App Client Secret

This assumes you have an App Client that has an app secret key set.

The main thing here is you need to generate a secret hash to send along with the command.

You can do that by creating a little python program to generate it for you when you need it:

#!/usr/bin/env python3

import sys
import hmac, hashlib, base64

if (len(sys.argv) == 4):
    username = sys.argv[1]
    app_client_id = sys.argv[2]
    key = sys.argv[3]
    message = bytes(sys.argv[1]+sys.argv[2],'utf-8')
    key = bytes(sys.argv[3],'utf-8')
    secret_hash = base64.b64encode(hmac.new(key, message, digestmod=hashlib.sha256).digest()).decode()

    print("SECRET HASH:",secret_hash)
else:
    (print("len sys.argv: ", len(sys.argv)))
    print("usage: ",  sys.argv[0], " <username> <app_client_id> <app_client_secret>")

Save the file someplace that you can execute it from like ~/bin/app-client-secret-hash and make it executable (chmod a+x ~/bin/app-client-secret-hash).

You will need:

• app-client-id – The client-id of the app client you are using
• app-client-secret – The secret of the app client you are using (its on the App Client page of the User Pool)
• USERNAME – The Username normally used to login to your Amplify app

To use:

~/bin/app-client-secret-hash  <username> <app_client_id> <app_client_secret>

Where of course you replace the arguments with the actual values.

The result is a secret-hash you will use in the following command to get the actual JWT credentials

aws cognito-idp admin-initiate-auth --user-pool-id us-east-1_XXXXXXXXXX --auth-flow ADMIN_USER_PASSWORD_AUTH --client-id XXXXXXXXXXXXX --auth-parameters USERNAME=username3,PASSWORD='secret password',SECRET_HASH='secret-hash' > creds.json

You could do the same thing with USER_PASSWORD_AUTH if you nee that instead

aws cognito-idp initiate-auth --auth-flow USER_PASSWORD_AUTH --client-id XXXXXXXXXXXXX --auth-parameters USERNAME=rob+admin,PASSWORD=XXXXXXXXX,SECRET_HASH='secret-hash' > creds.json

Using the Credentials

How you use these credentials depends on what tool or how you are trying to access your AppSync APIs.

From some Javascript

You can just add in the IdToken from the creds.json as an Authorization header when you build the request:

function graphQLFetcher(graphQLParams) {
  const APPSYNC_API_URL = "TYPE_YOUR_APPSYNC_URL";
  const credentialsAppSync = {
    Authorization: "eyJraWQiOiI1dVUwMld...",
  };
  return fetch(APPSYNC_API_URL, {
    method: "post",
    headers: {
      Accept: "application/json",
      "Content-Type": "application/json",
      ...credentialsAppSync,
    },
    body: JSON.stringify(graphQLParams),
    credentials: "omit",
  }).then(function (response) {
    return response.json().catch(function () {
      return response.text();
    });
  });
}

If you are using some GraphQL tool that needs to access your AppSync APIs. The tool should have a way that you can supply the token and it will add it as an Authorization header for its own requests.

Do let me know if you have some examples of tools that would make use of this.

References

• Explore AWS AppSync APIs with GraphiQL from your local machine
• [How do I troubleshoot “Unable to verify secret hash for client ” errors from my Amazon Cognito user pools API?](https://aws.amazon.com/premiumsupport/knowledge-center/cognito-unable-to-verify-secret-hash/ “How do I troubleshoot “Unable to verify secret hash for client ” errors from my Amazon Cognito user pools API?”)

The post Accessing AppSync APIs that require Cognito Login outside of Amplify first appeared on Cognizant Transmutation.

I’ve been itching to do some blogging about various projects I’ve been working on for both work and personal. In particular since I had the honor of being invited to be part of the AWS Community Builders I need to up my blogging game.

Joining the POSSE

One goal is to do it in the Publish (on your) Own Site, Syndicate Elsewhere POSSE style. I.E. publish on my personal blog but then have it (hopefully) automatically syndicated to other sites like Medium, Dev.to, Hashnode, etc. I.e. Write Once, Publish Everywhere.

Markdown, Emacs and Github at the Source

And I want to write it in Markdown with Emacs and have the authoritative source in Github. What more is there to say?

WordPress as the Personal Website

My personal website is based on WordPress running on AWS lightsail. I have a love / hate relationship with WordPress. Its one of those technologies that are powerful because so many people use it. And I have to help other folks with their WordPress setups, so I want to keep my finger in it. I’ve tried the various static sites and its been at least so far, worth keeping it there.

Unfortunately, WordPress is also the most painful to work with Markdown and have content come from Github.

Git it Write makes it possible

I have found what looks like a good solution: Git it Write

It is a WordPress plugin that allows you to connect a github repo to your WordPress instance. It uses a webhook so that everytime you update a specified branch of a github repo, it will push the markdown and images from the repo into the WordPress as a Post, Page Ad, Reusable Block, or Attachment. It uses YAML frontmatter in the markdown source to control some of the meta info for the post.

You organize the file hierarchy in the repo to match the Permalink hierarcy of your website. In my case, my default permalink is a custom /%category%/%postname%/ . And the file layout is like this:

.
├── LICENSE
├── README.md
├── _images
│   ├── permalink-settings.png
│   └── san-juan-mountains.jpg
└── posts
    ├── anti-ageing
    ├── blogging
    │   └── first-git-blog-post.md
    ├── how-the-world-works
    │   ├── creating_the_future_of_abundance
    │   └── demand_transformation
    ├── howto
    ├── macintosh
    ├── robotics-2
    ├── scalable-deployment
    ├── sysadmin
    ├── telecom
    └── uncategorized

Right now I only have the one article that you are reading now first-get-blog-post.md but I put in all the other categories I already had in my blog from before as directories as placeholders.

Also notice the _images directory. Unfortunately, you have to put all the images you use in any post in this one top level _images directory. So you have to make the filenames unique across posts and its a shame in terms of keeping things organized. But the good news is the plugin takes care of geting the images into WordPress.

You refer to the image in our Markdown like:

![Permalink Settings](/_images/permalink-settings.png "Permalink Settings")

The setup of the plugin is pretty easy:

Just click on the + Add a new repository to publish posts from and fill in the info about your repo:

You can set a subdirectory in the repo if you want to carve up things like Posts, Pages, etc in the same repo.

NOTE: the _image_ directory is still at the top of the repo and shared across them all.

The documenation for Git it Write is at https://www.aakashweb.com/docs/git-it-write/

In any case, it seems like a pretty nice solution for now to allow me to write in markdown and make Git the authoritative source for posts. Which means I can use the git repo to push to other sites like Medium and Dev.to. My experiences attempting that will hopefully be in a future post.

The post Blogging Once More first appeared on Cognizant Transmutation.

The Dev team here at Omnyway wanted to start blogging on our company WordPress blog about all the cool Clojure stuff we’re open sourcing. But they all like to use Emacs Org Mode for their writing.

I had to figure out how to go from Emacs org mode to WordPress, so I am first trying it here on my personal blog. Since I use Spacemacs (in holy mode of course) as my form of Emacs, I wanted to add it as a Layer.

Spacemacs prefers you to have layers that combine packages and configuration. I could have just added it to dotspacemacs-additional-packages in the spacemacs init file but I wanted to try doing it as a layer. I’ve tried (unsuccessfully) to create my own layers before, but I was determined to get it to work this time! Turns out there isn’t really that much of an advantage of using a layer in this case other than being able to pull it from github dynamically.

<META-x> configuration-layer/create-layer

;;; packages.el --- org2blog layer packages file for Spacemacs.

(setq org2blog-packages
  '((org2blog :location (recipe :fetcher github
                                :repo "org2blog/org2blog"))))

(defun org2blog/init-org2blog ()

  (use-package org2blog)
  ;(require 'org2blog-autoloads)
  )
;;; packages.el ends here

dotspacemacs-configuration-layers
 '(
   (org2blog :variables
     org2blog/wp-blog-alist '(("my.blog.com"
                               :url "https://my.blog.com/xmlrpc.php"
                               :username "joe")))
    ;; ... additional layers                               
  )

META-x org2blog/wp-login

META-x org2blog/wp-new-entry

The post First Post with Spacemacs and org2blog first appeared on Cognizant Transmutation.

Then they came for the Boing Boing Readers, and I did not speak out—
Because I was not a  Boing Boing Reader.

Then they came for the Linux Users, and I did not speak out—
Because I was not a Linux User.

Then they came for people who mocked the NSA, and I did not speak out—
Because I was not mocking the NSA.

Then they came for the Jews (they always eventually come for the Jews even when Jews think they are mainstream), and I did not speak out—
Because I was not a Jew.

Then they came for me—and there was no one left to speak for me.

The post First they came for the Whistleblowers, and I did not speak out first appeared on Cognizant Transmutation.

But many other tools don’t yet support the new format config file or multi-profiles. But they do support shell environment variables. So I wrote a simple ruby script that

• Allows you to specify the profile name as an argument
• Reads in the config file ~/.aws/config
• Outputs the export statements for publishing the environment variables
  • You can eval the output to set the environment of your current shell session

So if you had a config file ~/.aws/config that looked like this:

[default]
aws_access_key_id=AKI***********2A
aws_secret_access_key=jt41************************************p
region=us-east-1

[profile foo]
aws_access_key_id=0K***************K82
aws_secret_access_key=2b+***********************************1g
region=us-east-1

[profile bar]
aws_access_key_id=AKI**************GA
aws_secret_access_key=MG************************************/d
region=us-east-1

If you don’t specify any argument to the command it will output the default profile:
 $ aws_switch
export AWS_ACCESS_KEY_ID=AKI***********2A
export AWS_SECRET_ACCESS_KEY=jt41************************************p
export AMAZON_ACCESS_KEY_ID=AKI***********2A
export AMAZON_SECRET_ACCESS_KEY=jt41************************************p
export AWS_ACCESS_KEY=AKI***********2A
export AWS_SECRET_KEY=jt41************************************p

If you specified a profile (in this case foo):
$ aws_switch foo
export AWS_ACCESS_KEY_ID=0K***************K82
export AWS_SECRET_ACCESS_KEY=2b+***********************************1g
export AMAZON_ACCESS_KEY_ID=0K***************K82
export AMAZON_SECRET_ACCESS_KEY=2b+***********************************1g
export AWS_ACCESS_KEY=0K***************K82
export AWS_SECRET_KEY=2b+***********************************1g

You would actually use it by eval’ing the output of aws_switch so it sets the variables in the environment of yhour current shell:
eval `aws_switch foo`

Here’s the code for aws_switch. Put it in someplace in your $PATH and make sure to chmod 0755 the file so its executable:
#!/usr/bin/env ruby
require 'inifile'

configs = IniFile.load(File.join(File.expand_path('~'), '.aws', 'config'))

profile_name_input = ARGV[0]
case profile_name_input
when 'default'
  profile_name = 'default'
when nil
  profile_name = 'default'
when ""
  profile_name = 'default'
else
  profile_name = "profile #{profile_name_input}"
end

id = configs[profile_name]['aws_access_key_id']
key = configs[profile_name]['aws_secret_access_key']

puts "export AWS_ACCESS_KEY_ID=#{id}"
puts "export AWS_SECRET_ACCESS_KEY=#{key}"
puts "export AMAZON_ACCESS_KEY_ID=#{id}"
puts "export AMAZON_SECRET_ACCESS_KEY=#{key}"
puts "export AWS_ACCESS_KEY=#{id}"
puts "export AWS_SECRET_KEY=#{key}"
The post CLI to Switch Amazon AWS Shell Environment Credentials first appeared on Cognizant Transmutation.
]]>
					
		
		
		1616	
		
		
		https://www.ibd.com/how-the-world-works/demand_transformation/message-to-my-senator-boxer-uphold-your-oath-of-office-squash-shadow-secret-govt/
		
		
		Sat, 13 Jul 2013 21:22:18 +0000
				
		
		
		
		
		
		http://blog2.ibd.com/?p=1599

					Just a reminder you swore an oath of office to uphold the Constitution but you are not upholding it if you are not investigating and prosecuting those in all branches of the government that have been sidestepping the Constitution. The 13 years of Cheney/Obama administrations has set up a shadow secret government with its own courts, laws and interpretations of…

The post Message to My Senator Boxer: Uphold your Oath of Office: Squash Shadow Secret Gov’t first appeared on Cognizant Transmutation.
]]>
										Just a reminder you swore an oath of office to uphold the Constitution but you are not upholding it if you are not investigating and prosecuting those in all branches of the government that have been sidestepping the Constitution.

The 13 years of Cheney/Obama administrations has set up a shadow secret government with its own courts, laws and interpretations of the public laws.
Members of at least the current administration have now been proven to have lied under oath in front of congressional hearing.
But nothing has been done. Instead the whistleblowers are in jail or forced to seek asylum in other nations and the real criminals are in the seats of the White House, Congress, the Judiciary and the Media.
I’m not even bothering to write to Diane “NSA” Feinstein but I for some reason still have hope that maybe you have a bone of integrity left in your body.
You are being called to get out of your comfort zone and safeguard our Democracy before its too late (though it may be too late already, especially if you and at least some colleagues don’t do something about it)
The post Message to My Senator Boxer: Uphold your Oath of Office: Squash Shadow Secret Gov’t first appeared on Cognizant Transmutation.
]]>
					
		
		
		1599	
		
		
		https://www.ibd.com/how-the-world-works/data-wants-to-be-free-as-in-freedom/
					https://www.ibd.com/how-the-world-works/data-wants-to-be-free-as-in-freedom/#comments
		
		
		Tue, 09 Apr 2013 09:44:56 +0000
				
		
		
		
		
		
		
		
		
		http://blog2.ibd.com/?p=1587

					Tonight I was at the Sensored Meetup #10: Data! APIs! Standards!. Besides some great thought provoking talks, there was some great discussions afterward that got me thinking more clearly about some stuff that has been bubbling in my brain. Scott McNealy Was Right – Privacy: ‘Get Over It’ I really thought McNealy was wrong when he said way back in 1999 that consumer privacy issues…

The post Data Wants to be Free (as in Freedom) first appeared on Cognizant Transmutation.
]]>
										Tonight I was at the Sensored Meetup #10: Data! APIs! Standards!. Besides some great thought provoking talks, there was some great discussions afterward that got me thinking more clearly about some stuff that has been bubbling in my brain.

Scott McNealy Was Right – Privacy: ‘Get Over It’
I really thought McNealy was wrong when he said way back in 1999 that consumer privacy issues are a “red herring.” “You have zero privacy anyway,” But today in conversation with one of the participants, Antoine Lizee, about how can we get people’s  Medical data available to medical researchers I realized that McNealy was correct.
We both felt that if medical sensor and other data from  millions of people could be made available in some open source form to researchers, huge breakthroughs in medical science would quickly emerge just from modern data mining, machine learning and statistical processing. Of course the issue of privacy came up almost immediately. But from his experience and from recent news that even anonymized DNA sequences can be traced back to an individual’s identity. So even with anonymization, its almost impossible to completely protect an individual’s identity in light of modern big data techniques.
I wondered, “Actually, what are people real fears about their Medical Data getting out?”. Is it any different than 5 or ten years ago when people said they would NEVER use a credit card on the Internet

How long and what would it take to have a similar change in mass mentality that would allow folks to not mind that their medical data might be use “on the Internet”?
Big Data Processing of  Medical Sensors: A Solution to Rising Health Care Costs
I have long believed that if the data collected from medical sensors and the burgeoning world of the Quantified Self could be aggregated and made available to researchers (and not just “medical researchers”) we would enter a new golden era of medical breakthrough and real cures for major illnesses.
With sample sizes of MILLIONs instead of the 10 to 100 people in most modern medical studies, just using statistical processing on the billions of data samples  patterns of health and illness will practically just apear. That alone would make it worthwhile for us to do it, the government (or insurance companies) to fund it and for individuals to feel there would be a value to allow their data to be aggregated. Even if it meant that their data may leak out.
And using similar Big Data techniques used today to sell more stuff on the Internet (like we did at my last company Runa), we could map some of those discoveries of patterns back to the real time processing of individual’s sensor data to let them know if their personal real time data stream indicates they are about to have a heart attack or something.
Just Do It
My conclusion was that we need to break the logjam and start some projects that demonstrate how powerful it will be to do open Big Data medical research using aggregated data. One way would be to get companies with silos of Quantified Self and similar data to make it available (with permission from the individuals) to open medical research. I’m sure there are other short term ways the community can come up with to show that this kind of research can have huge positive results.
Legal Protections are More Viable than Technical Protections
Mechanisms, that can be publicly audited,  should be made to make the data a anonymized as possible but as mentioned earlier, the nature of medical data is inherently personally identifiable, especially if drawn from multiple sources and linked with other publicly available personal info (aka Facebook and the like).
There can be huge benefits of allowing at least some explicit linkage of personal data to the person. The primary one would be to allow the processor of the data to notify the individual if they found patterns that would indicate a medical problem or would predict a high probability of a future medical problem.
So we need the aggregators and users of this huge pool of data to be responsible and we need to make sure individuals don’t have to worry about discrimination or other negative impacts of their medical info leaking out.
This is much more a legal issue than a technical one. There already is The Genetic Information Nondiscrimination Act of 2008 and related laws that protects Americans from discrimination based on their genetic information in both health insurance (Title I) and employment (Title II). Just as the laws and policies of banks limits the risk of using your Credit Card on the Internet makes people much more comfortable, we need appropriate laws and corporate policies to allow people to feel comfortable sharing their medical and personal sensor data as well.
So if we could implement as much technical and legal means as possible combined with the huge individual and collective win of using machine learning and statistical processing on the huge corpus of personal & medical data that is already being collected by individuals, we could come up with major new cures and solutions to age old health problems and solve the US core economic problem (Health Care Costs) in one very low cost way.
The post Data Wants to be Free (as in Freedom) first appeared on Cognizant Transmutation.
]]>
					
					https://www.ibd.com/how-the-world-works/data-wants-to-be-free-as-in-freedom/feed/
			1
		
		
		1587