• Read the table of contents
• Rapidly skim through the various sections of the book
• Determine what you want to get out of the book
• Ask yourself questions about what you briefly read

References

• https://www.scotthyoung.com/blog/2015/01/19/speed-reading-redo/

• What did you do this week/today?
• Do you want to talk about anything? (Not language related)
• Summarize tasks given during the exchange
• Plan next exchange

Structured

• Pronunciation
• Can you say ...?
• How do you say ...?
• Goal specific discussions

Unstructured

• What do you think of ...?
• What do you want ...?

Context

Learned in this study

Things to explore

Overview

AWS

AWS has the concept of groups, users, roles and policies.

Groups

A group is a list of users to which are assigned policies (permissions).

A useful feature they also provide is the Access Advisor, which allows administrators to observe when certain policies are being used and by which users.

To keep things simple, groups cannot be nested into other groups.

Users

Users represent an entity that has access to the AWS platform. They may access AWS either programmatically and/or through the console to administer the account.

During the using creation process, the creator has the ability to assign the user to a group, copy permissions from an existing user or attach policies to the user.

Upon creation of a user with programmatic access, the user is generally given an access key with its corresponding secret.

Roles

Roles are very similar to groups conceptually, but instead of being "persistent", they are temporary. While you will generally assign one or many groups to a user, roles are not assigned to a user (or vice-versa, a user is not assigned one or many roles) but given based on certain criteria. A user takes a given role and only receives this role's policies/permissions until he returns to his own identity.

Policies

A policy is a set of rules that determines the permissions given to a user, group or role. It has a name, description and a policy document, which describes the permissions.

The policy document is a JSON formatted object which contains a version and a list of statements. Each statement has an effect (Allow/Deny), a list of actions and a list of resources to which it applies.

You can learn more about AWS policies evaluation logic. Their IAM Policy Reference might also prove useful in understanding the various bits that compose the policy document.

Actions

Within AWS, each service has a unique lowercase identifier¹. Within each of these services, a list of actions exists, which can be granted (or denied) to an identity. Examples of actions are:

• *: Allowed to use all actions under all services
• s3:*: Allowed to use all actions under the s3 service
• s3:GetObject: Allowed to use the GetObject action under the s3 service

Resources

Resources represent entities within their given service. For example, arn:aws:s3:::some-bucket/* represents the content under the some-bucket bucket in the s3 service.

Format : arn:$partition:$service:$region:$account-id:$resource²

See also

• Policy evaluator

References

• https://blog.gopheracademy.com/advent-2015/hydra-auth/

• It's easy to do things such as checking your email or going on reddit as they are very short term tasks (can be started and completed in less than 10s).
• Long term tasks on the other hand requires you to save and restore your mental state every time you transition to and from them.

Steps

• Build a list of task/items
  List everything that you want to get out of your head. The goal here is to make explicit as much as possible.
• Deconstruct tasks into their pre-requisites and follow-up tasks
  There are a couple of important things to consider when one wants to prioritize their task list. One is that even if a task is at the top of the list, it might not be possible to do it until its dependencies are fulfilled. This in turn means that all dependencies will have a superior priority to this task automatically.
  However, it frequently happens that what we consider dependencies can in fact be delayed or temporarily replaced by another solution which takes less time to implement or costs less (or for whatever other reason can replace the original dependency).
• Split tasks into 2 groups (and repeat this process)
  The idea here is to quickly filter out as many tasks as possible. As you may have noticed, I have not specified the filtering predicate. It is up to you to filter out your tasks such that you will have the least amount to filter at once. Examples of predicates you could use are "will/will not do", "want/do not want", "need/do not need", "like/do not like" and so on.
• Prioritize the tasks that will have to be done
  After a certain number of iterations of the previous step, you should arrive at a point where the items you have all need to be done, but you do not know in which order you have to do them (or want to do them).

Methods

4 quadrants method

Urgent/Important
Not Urgent/Important
Urgent/Not Important
Not Urgent/Not Important

Analytic Hierarchy Process

Binary Search Tree

Planning Game

100-Point Method

Prioritizing reading

• What you feel like reading
• Reading dependencies
• ROI evaluation

References

• Karlsson, Joachim, Claes Wohlin, and Björn Regnell. "An evaluation of methods for prioritizing software requirements." Information and Software Technology 39.14 (1998): 939-947.
• Karlsson, Joachim, Stefan Olsson, and Kevin Ryan. "Improved practical support for large-scale requirements prioritising." Requirements Engineering 2.1 (1997): 51-60.
• Ahl, Viggo. "An experimental comparison of five prioritization methods: investigating ease of use, accuracy and scalability." (2005).
• Gill, Nasib Singh. "A Comparison among Various Techniques to Prioritize the Requirements." International Journal of Computer Science and Management Studies (IJCSMS) www. ijcsms. com 1.12: 601-607.
• http://www.gwern.net/Resorter