One thing I've been wondering about lately is when should one write blog articles (short articles ranging from 250 to 1000 words) or articles (1000+ words) which would be updated (in)frequently but not be as easily consumable.
The main reason I've preferred articles over blog articles is that it makes it possible to keep articles "alive", while once a blog article has been published, it will not evolve over time. By the time it is posted, it is effectively dead and has very little reason to change.
Being a programmer, I've always enjoyed seeing software project evolve over the years. They start small and grow big and complex over time. I like the satisfaction of seeing something grow step by step, and because of that, I've liked the idea of writing about specific topics and seeing these topics and articles change over time.
The problem with articles however is that it is difficult for visitors to consume. Some articles might grow large and complex. Furthermore, it is difficult for visitors to notice any changes from the last time they've come onto the blog.
Another thing is that articles allow the author to "refactor" what he has written, or rewrite/rephrase/reword, such that the article itself improves over time. With a blog article, it is still possible to do so, but the expectation is that a visitor that has already seen the blog article will not re-read it. And here's the important difference between the two: I expect blog articles to be consumed once, but articles to be consumed multiple times. This expectation is likely wrong. The only person that is likely to consume the same article over and over is its author. Visitors may come to the blog many times, but they are unlikely to expect articles to change over time. An extreme example of this idea would be Wikipedia. People will consult the page of the topic they are interested in, but once they've read it, they aren't likely to come back to it again. The only reason they might do so is if they contribute to it.
What this means is that it is still acceptable to improve both blog articles and articles. The difference lies in how we expect our audience to consume each ones. Articles are likely to be seen as references while blog posts are likely to be perceived as an ephemeral observation. One should expect both to be consumed at best once by a visitor, and that the visitor will not come again to see if it has changed.
Thus, in the end, what matters is what we want to communicate with our audience. Do I want to tell you about a thought (a blog article) or do I want to tell you about some information that is likely to evolve over time (an article).
In the case of my machine learning and artificial general intelligence research, what makes sense is to communicate discoveries or shifts in approaches through blog articles while using articles as a location for thoughts to be worked on.
- Have a question
- Ask LLMs
- Identify the field that would best answer this question
- Search online
- Search for articles and books on the topic
- Determine the likelihood that this field has already been researched
- 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
- 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
- Pronunciation
- Can you say ...?
- How do you say ...?
- Goal specific discussions
- What do you think of ...?
- What do you want ...?
Identity and access management
History / Edit / PDF / EPUB / BIB / 3 min read (~470 words)AWS has the concept of groups, users, roles and policies.
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 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 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.
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.
Within AWS, each service has a unique lowercase identifier1. 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 servicess3:*: Allowed to use all actions under thes3services3:GetObject: Allowed to use theGetObjectaction under thes3service
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:$resource2