It's time for one of my favorite steps in the design phase: data modeling. Much like the UI design exercise in my previous post, this process is a way of realizing the requirements and starting to visualize how things will actually work.
We'll also see how easy it is to fall into the trap of scope creep.
Let's start with that data model.
Tuesday, September 22, 2015
Sunday, September 6, 2015
AWS IAM for Developers
Here's a quick break while I work on the next entry in my app creation series.
The Office of Information Technology at Notre Dame is fully invested in migrating our data center to the cloud using Amazon Web Services. On Twitter, we call it #NDCloudFirst. Earlier this summer, we started the Michiana AWS Meetup in conjunction with local AWS consultant shop Trek10.
Last Thursday, I took the group on a deep dive into AWS' Identity and Access Management. This talk isn't a guide on writing IAM policies; rather, it illuminates how common scripting and web development tasks are influenced by IAM policies, and what steps developers can take to work with them. Concepts include:
The Office of Information Technology at Notre Dame is fully invested in migrating our data center to the cloud using Amazon Web Services. On Twitter, we call it #NDCloudFirst. Earlier this summer, we started the Michiana AWS Meetup in conjunction with local AWS consultant shop Trek10.
Last Thursday, I took the group on a deep dive into AWS' Identity and Access Management. This talk isn't a guide on writing IAM policies; rather, it illuminates how common scripting and web development tasks are influenced by IAM policies, and what steps developers can take to work with them. Concepts include:
- handling multi-factor authentication requirements using Simple Token Service (CLI and Ruby)
- passing roles to EC2 instances
- assuming roles (CLI/Ruby) -- how and why
- role trust relationships
- s3 bucket policies (restricting a bucket to a role)
Subscribe to:
Posts (Atom)