vault backup: 2026-01-05 13:03:55
This commit is contained in:
windyboy
@@ -0,0 +1,32 @@
|
||||
Tags: [[Podcast]] [[Community]] - [[Audience]]
|
||||
Podcast: [[The Future Belongs to Creators]]
|
||||
|
||||
## Highlights:
|
||||
|
||||
What is an audience, how do you find them
|
||||
- People who want to hear from you and would miss you if you didn't show up
|
||||
- People who want follow you around even when you jump off and change
|
||||
|
||||
Audience building = Community Building
|
||||
|
||||
Kevin Kelly - 1000 true fans principles
|
||||
|
||||
That makes it so you won't need to make a lot of money on each of them to make a very good living (100$/years -= 100k / years revenue )
|
||||
|
||||
To start pick the friends, the people you know who would be interesting in the topics
|
||||
- Text them or connect with them
|
||||
- Some will say no and you need to get used to it too
|
||||
- Habit skill of rejection and learn how to make the ask
|
||||
|
||||
Show up consistantly no matter the result
|
||||
|
||||
You don't control the result but you control the process
|
||||
|
||||
If you're one step ahead of your audience then everything you learn as value for them to learn
|
||||
- Concept of Leading learner
|
||||
|
||||
People wants connection and to get connection you need to tell the full story and be authentic
|
||||
|
||||
People connect the most when you're authentic with your story, the mistake you made, the errors, the problems
|
||||
|
||||
Tell the story or teach and just switch between the 2 as you see fit
|
||||
@@ -0,0 +1,5 @@
|
||||
### Notes
|
||||
```dataview
|
||||
table file.ctime as Date from "300-resources/Community"
|
||||
sort file.name
|
||||
```
|
||||
@@ -0,0 +1,29 @@
|
||||
Tags: [[Article]] [[Community]] - [[Email Marketing]]
|
||||
Author: Substack Blog
|
||||
From: email
|
||||
|
||||
## Highlights:
|
||||
Write down your answers to these questions:
|
||||
- Who do you want to bring together?
|
||||
- Why do they want to come together?
|
||||
|
||||
Bailey explained that it’s especially good when you can describe your audience in terms of behavior and motivations rather than demographics; the latter might even be a legacy from advertising, which tends to put us into categories (think “35-44 year old urban working mom”).
|
||||
|
||||
By contrast, describing your audience in terms of a shared perspective creates the space for something that anyone can be a part of
|
||||
- ` “Being at the surprising center of a Venn diagram can feel really impactful and meaningful”. `
|
||||
|
||||
Try to write a sentence that brings these two parts together (this also makes for a great one-sentence description for your Substack!):
|
||||
- This community brings together [WHO] so we can [WHY].
|
||||
- For example, Bailey shared the story of YouTubers John and Hank Green, whose community of Nerdfighters brings together “nerds and the ‘otherwise out of sync’” (who) to “increase awesome and decrease world suck” (why).
|
||||
- What do they need more of?
|
||||
- What change do they desire?
|
||||
- What’s a problem that only they can solve together?
|
||||
|
||||
Think of a shared activity that helps your community achieve their “why”. In other words: what do people get together to do? In her experience, Bailey has found that people tend to get together in order to do something that is better in a group, like teach each other, support each other, and meet up locally
|
||||
|
||||
Your shared activity should have the following traits:
|
||||
- Purposeful: It brings your community’s “why” to life
|
||||
- Participatory: It gives others the chance to contribute (ideally, you shouldn’t do all the work!)
|
||||
- Repeatable: It takes place regularly, which builds a habit or ritual (Bailey noted that organizing a community is like running a cafe: you need to keep the doors open for your patrons.)
|
||||
|
||||
Your writing is a beacon for like-minded readers, even if you don’t know who they all are yet! Giving your readers the chance to get to know you, as well as their fellow subscribers, can be a powerful experience. Once you know who your audience is, the what’s and how’s of building your community will easily follow.
|
||||
@@ -0,0 +1,115 @@
|
||||
|
||||
|
||||
Storage:
|
||||
azure object:
|
||||
bucket(container): synapse
|
||||
region: West US 2
|
||||
endpoint_url: https://matrixserver.blob.core.windows.net/
|
||||
aws_access_key_id: matrixserver
|
||||
aws_secret_access_key: vuEGDMi5x1DPdYqCkoG3ApOBbq3CppPOa0qExCdWEWgSdxl/puQNsc7kZQ7zI9fX8daWGGGb2yBU+AStj1VVSA==
|
||||
|
||||
connection: DefaultEndpointsProtocol=https;AccountName=matrixserver;AccountKey=vuEGDMi5x1DPdYqCkoG3ApOBbq3CppPOa0qExCdWEWgSdxl/puQNsc7kZQ7zI9fX8daWGGGb2yBU+AStj1VVSA==;EndpointSuffix=core.windows.net
|
||||
|
||||
flexifyio:
|
||||
Access Key ID
|
||||
FlIO73xaxZt86teyIm4F5N7B
|
||||
Secret Access Key
|
||||
h7gjsbc5QJMWjgmA24wRpWdLCBC9VWmgJv1sm8
|
||||
|
||||
|
||||
managed flexifyio:
|
||||
Endpoints (S3)
|
||||
|
||||
s3.flexify.io
|
||||
|
||||
s3.us-east-1.aws.flexify.iocontent_copy
|
||||
|
||||
s3.us-west-1.aws.flexify.iocontent_copy
|
||||
|
||||
Access key
|
||||
|
||||
FlIO6ufBeax0c2II1LI1El2zcontent_copy
|
||||
|
||||
Secret key
|
||||
|
||||
eTwlfXvsJKkJJRS5lBe0MFI73Mdo9zdR105VTBNU
|
||||
|
||||
|
||||
|
||||
|
||||
Endpoint (S3)
|
||||
|
||||
stor.chans.xyz
|
||||
|
||||
Access key
|
||||
|
||||
FlIO8hB9RMewbeOQiDi5omT
|
||||
|
||||
Secret key
|
||||
|
||||
TY5c8siV7gNwIGJ8wq4dBBzN7MfsF5CAWeywLyze
|
||||
|
||||
|
||||
|
||||
Access Key ID
|
||||
FlIO73xaxZt86teyIm4F5N7B
|
||||
|
||||
Secret Access Key
|
||||
h7gjsbc5QJMWjgmA24wRpWdLCBC9VWmgJv1sm8
|
||||
|
||||
|
||||
amazon s3:
|
||||
"AWS":"arn:aws:iam::`AccountIDWithoutHyphens`:root"
|
||||
"AWS":"arn:aws:iam::587891510942:windyboy"
|
||||
|
||||
```json
|
||||
1. {
|
||||
2. "Version":"2012-10-17",
|
||||
3. "Statement":[
|
||||
4. {
|
||||
5. "Sid":"AddCannedAcl",
|
||||
6. "Effect":"Allow",
|
||||
7. "Principal": {"CanonicalUser":"fecdb8da051398108edd3ed57e7e0d8457180461bd14d0a77eec6ea6fbff954a"},
|
||||
8. "Action":["s3:**"],
|
||||
9. "Resource":"arn:aws:s3:::windy-matrix/*"
|
||||
11. }
|
||||
12. ]
|
||||
13. }
|
||||
|
||||
```
|
||||
Account name
|
||||
|
||||
windyboy
|
||||
|
||||
Email address
|
||||
|
||||
windyboy@gmail.com
|
||||
|
||||
AWS account ID
|
||||
|
||||
587891510942
|
||||
|
||||
Canonical user ID
|
||||
|
||||
fecdb8da051398108edd3ed57e7e0d8457180461bd14d0a77eec6ea6fbff954a
|
||||
|
||||
|
||||
access:
|
||||
AKIAYRYIQR2POZMGOCM4
|
||||
|
||||
Secret access key：
|
||||
myoTKuUYxY202mo406tO5wRCtWu3frl1TQkhEpAe
|
||||
|
||||
region:
|
||||
us-east-1
|
||||
|
||||
|
||||
azure:
|
||||
account:
|
||||
matrixserver
|
||||
|
||||
sas:
|
||||
uwhhhtwhg0DXJbqHDC+4zsMTUA06SXT3JkO80Tz6zGKoVp58Nbv6y6otlczb7w0sgCXzUD/BesV5+AStnfXHEQ==
|
||||
|
||||
string:
|
||||
DefaultEndpointsProtocol=https;AccountName=matrixserver;AccountKey=uwhhhtwhg0DXJbqHDC+4zsMTUA06SXT3JkO80Tz6zGKoVp58Nbv6y6otlczb7w0sgCXzUD/BesV5+AStnfXHEQ==;EndpointSuffix=core.windows.net
|
||||
@@ -0,0 +1,42 @@
|
||||
**1. [SLOW COOKER CHICKEN ADOBO WITH PINEAPPLE](https://blog.myfitnesspal.com/slow-cooker-chicken-adobo-with-pineapple/) MYFITNESSPAL'S RECIPES**
|
||||
|
||||
Nutrition (per serving): Calories: 340; Total Fat: 14g; Saturated
|
||||
Fat: 4g; Monounsaturated Fat: 6g; Cholesterol: 231mg; Sodium: 383mg;
|
||||
Carbohydrate: 6g; Dietary Fiber: 2g; Sugar: 3g; Protein: 44g
|
||||
|
||||
**2. [SALMON AND SPINACH FRITTATA](https://blog.myfitnesspal.com/salmon-and-spinach-frittata/) MYFITNESSPAL'S RECIPES**
|
||||
|
||||
Nutrition (per serving): Calories: 152; Total Fat: 6g; Saturated
|
||||
Fat: 1g; Monounsaturated Fat: 1g; Cholesterol: 94mg; Sodium: 176mg;
|
||||
Carbohydrate: 6g; Dietary Fiber: 1g; Sugar: 5g; Protein: 20g
|
||||
|
||||
|
||||
**3. [THAI CURRY TOFU OVER SWEET POTATOES](https://blog.myfitnesspal.com/thai-curry-tofu-over-sweet-potatoes/) MYFITNESSPAL'S RECIPES**
|
||||
|
||||
Nutrition (per serving): Calories: 397; Total Fat: 17g; Saturated
|
||||
Fat: 12g; Monounsaturated Fat: 1g; Cholesterol: 0mg; Sodium: 379mg;
|
||||
Carbohydrate: 48g; Dietary Fiber: 11g; Sugar: 19g; Protein: 16g
|
||||
|
||||
**4. [BARLEY AND PROVENCAL VEGETABLES IN VINAIGRETTE](https://blog.myfitnesspal.com/barley-and-provencal-vegetables-in-vinaigrette/) MYFITNESSPAL'S RECIPES**
|
||||
|
||||
Nutrition (per serving): Calories: 284; Total Fat: 8g; Saturated
|
||||
Fat: 2g; Monounsaturated Fat: 4g; Cholesterol: 5mg; Sodium: 387mg;
|
||||
Carbohydrate: 43g; Dietary Fiber: 10g; Sugar: 6g; Protein: 11g
|
||||
|
||||
**5. [SALMON CAKES ON MIXED GREENS](https://blog.myfitnesspal.com/salmon-cakes-on-mixed-green-salad) MYFITNESSPAL'S RECIPES**
|
||||
|
||||
Nutrition (per serving): Calories: 250; Total Fat: 12g; Saturated
|
||||
Fat: 1g; Monounsaturated Fat: 3g; Cholesterol: 0mg; Sodium: 156mg;
|
||||
Carbohydrate: 11g; Dietary Fiber: 3g; Sugar: 4g; Protein: 23g
|
||||
|
||||
**6. [DUKKAH-CRUSTED CHICKEN SHAWARMA SALAD WITH TAHINI RANCH](https://blog.myfitnesspal.com/dukkah-crusted-chicken-shawarma-salad-with-tahini-ranch/) MYFITNESSPAL'S RECIPES**
|
||||
|
||||
Nutrition (per serving): Calories: 329; Total Fat: 15g; Saturated
|
||||
Fat: 2g; Monounsaturated Fat: 8g; Cholesterol: 41mg; Sodium: 352mg;
|
||||
Carbohydrate: 31g; Dietary Fiber: 6g; Sugar: 6g; Protein: 21g
|
||||
|
||||
**7. [CREAMY CAULIFLOWER AND CARROT SOUP](https://blog.myfitnesspal.com/creamy-cauliflower-and-carrot-soup/) MYFITNESSPAL'S RECIPES**
|
||||
|
||||
Nutrition (per serving): Calories: 263; Total Fat: 15g; Saturated
|
||||
Fat: 3g; Monounsaturated Fat: 9g; Cholesterol: 7mg; Sodium: 238mg;
|
||||
Carbohydrate: 24g; Dietary Fiber: 7g; Sugar: 12g; Protein: 11g
|
||||
@@ -0,0 +1,5 @@
|
||||
### Notes
|
||||
```dataview
|
||||
table file.ctime as Date from "300-resources/Cooking"
|
||||
sort file.name
|
||||
```
|
||||
@@ -0,0 +1,17 @@
|
||||
## Ingredients
|
||||
- 6 slices bread
|
||||
- 1/2 onion, grated
|
||||
- 1/4 cup shredded Swiss cheese
|
||||
- 1/2 cup milk
|
||||
- 2 eggs
|
||||
- 1/2 teaspoon dry mustard
|
||||
## Directions
|
||||
- Preheat oven to 375 degrees F (190 degrees C).
|
||||
- Lightly grease 12 muffin tins.
|
||||
- Trim or cut bread into circles.
|
||||
- Place circles in bottom of muffin tins.
|
||||
- Distribute the onion and shredded cheese evenly between the muffin tins.
|
||||
- In a medium bowl, combine milk, eggs, mustard and pepper.
|
||||
- Divide between the muffin tins.
|
||||
- Bake in preheated oven for 20 minutes, or until a toothpick inserted into the center of a quiche comes out clean.
|
||||
|
||||
@@ -0,0 +1,27 @@
|
||||
|
||||
所需材料：
|
||||
|
||||
- 牛肉（切丝）：300克
|
||||
- 芹菜（切段）：300克
|
||||
- 鲜辣椒（切丝）：适量
|
||||
- 姜末：适量
|
||||
- 蒜末：适量
|
||||
- 盐：适量
|
||||
- 生抽：适量
|
||||
- 料酒：适量
|
||||
- 蚝油：适量
|
||||
- 淀粉：适量
|
||||
- 植物油：适量
|
||||
|
||||
做法：
|
||||
|
||||
1. 牛肉切成丝，加入盐、料酒、生抽和淀粉，搅拌均匀腌制10分钟左右。
|
||||
2. 热锅冷油，将腌制好的牛肉放入锅中煸炒至变色，盛出备用。
|
||||
3. 锅中留底油，加入姜末和蒜末煸炒出香味，加入鲜辣椒丝翻炒至变色出香味。
|
||||
4. 加入芹菜段煸炒至熟软，加入少许盐和料酒调味。
|
||||
5. 加入炒好的牛肉，加入蚝油，迅速翻炒均匀即可出锅。
|
||||
|
||||
温馨提示：
|
||||
|
||||
1. 鲜辣椒炒香的时间要控制好，一般需要炒到变色出香味即可。
|
||||
2. 加入鲜辣椒后可以再加入少许生姜末，提升菜肴的口感和香气。
|
||||
@@ -0,0 +1,48 @@
|
||||
|
||||
制作泡菜酸黄瓜的步骤如下：
|
||||
|
||||
材料：
|
||||
|
||||
- 新鲜的黄瓜或白萝卜，切成小块或薄片
|
||||
- 大蒜，切成小块或泥
|
||||
- 辣椒粉或新鲜的辣椒，根据口味添加
|
||||
- 盐，约为黄瓜重量的2%
|
||||
- 白糖，约为黄瓜重量的1%
|
||||
|
||||
步骤：
|
||||
|
||||
1. 准备一个干净的玻璃罐或容器，将黄瓜或白萝卜放入其中。注意，容器应该干燥，因为任何水分都可能影响发酵过程。
|
||||
|
||||
2. 在黄瓜中加入大蒜和辣椒粉，然后在上面撒上盐和白糖。
|
||||
|
||||
3. 用手轻轻地搓揉黄瓜，使它们与盐和糖混合，并开始释放水分。这个过程可能需要10到15分钟。
|
||||
|
||||
4. 将黄瓜压入罐中，使其尽可能地浸泡在其自身的水分中。如果水分不足，可以加入一些水，但不要让水超过黄瓜。
|
||||
|
||||
5. 将容器密封好，然后放置在室温下24小时。在此时间内，黄瓜将开始发酵。
|
||||
|
||||
6. 过了24小时后，打开罐子检查发酵情况。如果你看到了气泡和泡沫，那么你就成功地制作出了泡菜酸黄瓜！此时，你可以将其放入冰箱保存。
|
||||
|
||||
7. 等待几天或一周，黄瓜会越来越酸，并且味道会越来越好。你可以在任何时候品尝，直到你得到最喜欢的味道为止。
|
||||
|
||||
|
||||
注意事项：
|
||||
|
||||
- 在制作泡菜酸黄瓜时，要确保使用新鲜干净的材料，并在制作前彻底清洗。
|
||||
- 要准确地称量盐和糖的数量，因为这会影响到发酵的过程和结果。
|
||||
- 为了防止发酵过程中产生的气体无法逸出，可以选择松散的封口方式，如盖上一个松紧度适中的盖子或覆盖上一块纱布。不要使用密封的盖子，否则可能会导致容器爆裂。
|
||||
|
||||
如果您想为泡菜酸黄瓜添加其他香料以提升其风味，以下是一些常见的选择：
|
||||
|
||||
1. 姜：将姜切成小片或末，加入到泡菜酸黄瓜中。姜的味道会使泡菜酸黄瓜更具有咬劲和辛辣感。
|
||||
|
||||
2. 蒜薹：切碎一些蒜薹，加入到泡菜酸黄瓜中。蒜薹的味道会使泡菜酸黄瓜更加香气扑鼻。
|
||||
|
||||
3. 芝麻：将一些芝麻炒香，然后磨成粉末状，加入到泡菜酸黄瓜中。芝麻的味道会增加泡菜酸黄瓜的浓郁感。
|
||||
|
||||
4. 茴香籽：加入一些茴香籽到泡菜酸黄瓜中。茴香籽的味道会使泡菜酸黄瓜更加清爽和芳香。
|
||||
|
||||
5. 花椒：加入一些花椒到泡菜酸黄瓜中。花椒的味道会使泡菜酸黄瓜更加香辣和麻味。
|
||||
|
||||
|
||||
您可以根据自己的口味和喜好选择合适的香料，并根据量的大小和搭配程度进行调整，以获得您想要的口感和风味。
|
||||
@@ -0,0 +1,9 @@
|
||||
|
||||
## 2023.4.18 尝试
|
||||
小黄瓜原料： 1044克
|
||||
盐： 21.7克
|
||||
糖： 11.7克
|
||||
蒜末
|
||||
姜末
|
||||
蒜苔切碎
|
||||
芝麻
|
||||
@@ -0,0 +1,74 @@
|
||||
|
||||
key : 272f337c0d2c4407b930bde5e9846072
|
||||
endpoint: https://my-chatgpt.openai.azure.com/
|
||||
|
||||
```bash
|
||||
export AZURE_OPENAI_API_KEY="272f337c0d2c4407b930bde5e9846072"
|
||||
export AZURE_OPENAI_ENDPOINT="https://my-chatgpt.openai.azure.com/"
|
||||
```
|
||||
```
|
||||
|
||||
```.env
|
||||
# ChatGPT Settings (required)
|
||||
# Set the API Key from OpenAI
|
||||
OPENAI_API_KEY=272f337c0d2c4407b930bde5e9846072
|
||||
# To use Azure OpenAI API, set `OPENAI_AZURE` to true and `CHATGPT_REVERSE_PROXY` to your completion endpoint
|
||||
# OPENAI_AZURE=false
|
||||
OPENAI_AZURE=true
|
||||
CHATGPT_REVERSE_PROXY=https://my-chatgpt.openai.azure.com/
|
||||
|
||||
# Set the ChatGPT conversation context to 'thread', 'room' or 'both'.
|
||||
CHATGPT_CONTEXT=thread
|
||||
# Set the ChatGPT model to be used by the API. 'gpt-3.5-turbo' is the official ChatGPT-model from OpenAI
|
||||
# Note that the models are not free and will charge your OpenAI account depending on the usage of tokens
|
||||
#CHATGPT_API_MODEL=gpt-3.5-turbo
|
||||
CHATGPT_API_MODEL=gpt-4o
|
||||
# (Optional) Explicitly set the prefix sent to model at the beginning of a conversation
|
||||
#CHATGPT_PROMPT_PREFIX=Instructions:\nYou are ChatGPT, a large language model trained by OpenAI.
|
||||
# (Optional) Set to true if ChatGPT should ignore any messages which are not text
|
||||
#CHATGPT_IGNORE_MEDIA=false
|
||||
# (Optional) You can change the api url to use another (OpenAI-compatible) API endpoint
|
||||
#CHATGPT_REVERSE_PROXY=https://api.openai.com/v1/chat/completions
|
||||
# (Optional) Set the temperature of the model. 0.0 is deterministic, 1.0 is very creative.
|
||||
CHATGPT_TEMPERATURE=0.1
|
||||
# (Optional) (Optional) Davinci models have a max context length of 4097 tokens, but you may need to change this for other models.
|
||||
CHATGPT_MAX_CONTEXT_TOKENS=8192
|
||||
# You might want to lower this to save money if using a paid model. Earlier messages will be dropped until the prompt is within the limit.
|
||||
# CHATGPT_MAX_PROMPT_TOKENS=3097
|
||||
|
||||
# Set data store settings
|
||||
KEYV_BACKEND=file
|
||||
KEYV_URL=
|
||||
KEYV_BOT_ENCRYPTION=false
|
||||
KEYV_BOT_STORAGE=true
|
||||
|
||||
# Matrix Static Settings (required, see notes)
|
||||
# Defaults to "https://matrix.org"
|
||||
MATRIX_HOMESERVER_URL=
|
||||
# With the @ and :DOMAIN, ie @SOMETHING:DOMAIN - Not used if `MATRIX_ACCESS_TOKEN` is set.
|
||||
MATRIX_BOT_USERNAME=
|
||||
# Set `MATRIX_BOT_PASSWORD` the bot will print an `MATRIX_ACCESS_TOKEN` to the terminal
|
||||
MATRIX_ACCESS_TOKEN=
|
||||
# Not used if `MATRIX_ACCESS_TOKEN` is set.
|
||||
MATRIX_BOT_PASSWORD=
|
||||
|
||||
# Matrix Configurable Settings Defaults (optional)
|
||||
# Leave prefix blank to reply to all messages
|
||||
MATRIX_DEFAULT_PREFIX=!chatgpt
|
||||
MATRIX_DEFAULT_PREFIX_REPLY=false
|
||||
|
||||
# Matrix Access Control (optional)
|
||||
# Can be set to user:homeserver or a wildcard like :anotherhomeserver.example
|
||||
MATRIX_BLACKLIST=
|
||||
# `MATRIX_WHITELIST` is overriden by `MATRIX_BLACKLIST` if they contain same entry
|
||||
MATRIX_WHITELIST=
|
||||
|
||||
# Matrix Feature Flags (optional)
|
||||
MATRIX_AUTOJOIN=true
|
||||
MATRIX_ENCRYPTION=true
|
||||
# If you turn threads off you will have problems if you don't set CHATGPT_CONTEXT=room
|
||||
MATRIX_THREADS=true
|
||||
MATRIX_PREFIX_DM=false
|
||||
MATRIX_RICH_TEXT=true
|
||||
```
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
|
||||
|
||||
api key
|
||||
vscode:
|
||||
```
|
||||
sk-b3426ba1862543bd876be65b7f830499
|
||||
```
|
||||
|
||||
|
||||
zed:
|
||||
```
|
||||
sk-2f351b2c4d084e7c98a53311cf09e3da
|
||||
```
|
||||
@@ -0,0 +1,261 @@
|
||||
|
||||
|
||||
openapi key:
|
||||
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
|
||||
|
||||
[[Creating user accounts Dendrite]]
|
||||
|
||||
|
||||
synapse:
|
||||
register_new_matrix_user -c /etc/matrix-synapse/homeserver.yaml
|
||||
New user localpart: gpt
|
||||
Password: windyboy@2006
|
||||
token from element: syt_Z3B0_yBPDcvVUmXFgHeNPGRWa_32nnGL
|
||||
new token: syt_Z3B0_PPffEqKjnAjaIpcuRRuj_0LE1j5
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
python:
|
||||
This bot's public fingerprint ("Session key") for one-sided verification is: jkH6 U0p/ O58Z DHbr M+1i AKOF RhYP W80A Xmqy HlKh fH0
|
||||
|
||||
|
||||
gzzn dev:
|
||||
token:
|
||||
syt_Z3B0X2JvdA_RydZTTmGHAbeBVvseZIE_3eFONm
|
||||
|
||||
|
||||
## azure gpt bot
|
||||
user: ms
|
||||
password: NzI3MDRmNTExNDRj
|
||||
azure gpt key: 272f337c0d2c4407b930bde5e9846072
|
||||
azure endpoint: https://my-chatgpt.openai.azure.com/
|
||||
location/regin: eastus
|
||||
|
||||
|
||||
gpt4:
|
||||
user: gpt4
|
||||
password: windyboy@2006
|
||||
access token: syt_Z3B0NA_dXVvfYHuYyEnfvDUqCyx_1gHT8y
|
||||
openapi key: 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
|
||||
|
||||
|
||||
new google account openai
|
||||
matrix api: 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
|
||||
|
||||
mail gpt4:
|
||||
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
|
||||
|
||||
|
||||
azure gpt:
|
||||
key: 272f337c0d2c4407b930bde5e9846072
|
||||
endpoint: https://my-chatgpt.openai.azure.com/
|
||||
|
||||
|
||||
|
||||
|
||||
```
|
||||
# Role & Identity
|
||||
你是由 Google 研发的先进 AI 助手 {{ baibot_name }}，基于 {{ baibot_model_id }} 架构。
|
||||
当前会话启动时间: {{ baibot_conversation_start_time_utc }}。
|
||||
# Core Capabilities (针对 Gemini 优化)
|
||||
1. **深度推理**：拥有强大的逻辑分析、代码生成和数学计算能力。
|
||||
2. **长程记忆**：能够精准回顾和关联长对话历史中的细节，保持上下文一致性。
|
||||
3. **思维透明**：对于非显而易见的问题，必须通过"显式推理"展示你的思考路径。
|
||||
|
||||
# Thinking Protocol (思维协议)
|
||||
在回答用户之前，你必须执行以下思维循环：
|
||||
4. **意图识别**：用户真正想要解决的核心痛点是什么？隐含需求是什么？
|
||||
5. **知识检索**：在你的知识库和当前对话历史中检索相关信息。
|
||||
6. **逻辑推导**：构建解决路径，预判潜在的错误或陷阱。
|
||||
7. **自我修正**：检查生成的答案是否准确、无害且符合逻辑。
|
||||
|
||||
# Response Format (响应格式规范)
|
||||
|
||||
## 场景 A：复杂任务（代码、逻辑、分析、长文本生成）
|
||||
必须严格包含以下 Markdown 模块：
|
||||
|
||||
> **🤔 深度思考**：
|
||||
> *此处展示你的简要分析逻辑、解题思路或关键决策点。*
|
||||
|
||||
> **📋 详细解答**：
|
||||
> *此处提供具体的答案、代码实现或详细论述。*
|
||||
|
||||
> **💡 专家建议**：
|
||||
> *提供优化建议、潜在风险预警或延伸知识。*
|
||||
|
||||
## 场景 B：简单任务（问候、明确的短问题）
|
||||
- 直接给出简洁、准确的回答，无需展示思考过程。
|
||||
|
||||
# Interaction Guidelines (交互准则)
|
||||
- **准确性优先**：严禁编造事实。如果不知道，请直接说明。
|
||||
- **代码质量**：生成的代码必须是完整的、可执行的，并包含必要的注释。
|
||||
- **语言风格**：专业、客观、有条理。避免使用过度情绪化的词语。
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
|
||||
grok:
|
||||
|
||||
```
|
||||
base_url: https://openrouter.ai/api/v1
|
||||
api_key: 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
|
||||
|
||||
text_generation:
|
||||
model_id: x-ai/grok-4.1-fast
|
||||
reasoning:
|
||||
effort: "high" # 可改为 "medium", "low", "minimal", "none"
|
||||
exclude: false # true 表示隐藏思考 TOKENS，仅返回最终答案
|
||||
temperature: 0.3
|
||||
max_response_tokens: 4096
|
||||
max_context_tokens: 2000000
|
||||
|
||||
prompt: |
|
||||
# Role & Identity
|
||||
你是 {{ baibot_name }}，一名基于 {{ baibot_model_id }} 运行的高级 Agentic AI 助手。
|
||||
{{ baibot_model_id }} 是 xAI 的顶级模型之一，拥有 2M 超长上下文、强推理能力、可靠的工具调用机制。
|
||||
你的任务是：解决问题、提供高价值分析、执行工具调用，并保持专业性与安全性。
|
||||
当前会话启动时间：{{ baibot_conversation_start_time_utc }}。
|
||||
|
||||
# Core Capabilities（专为 Grok-4.1-Fast 调校）
|
||||
1. **Agentic Tool Calling**：在必要时自主调用工具，以实现精准查询、复杂任务分解与可执行方案。
|
||||
2. **Ultra-Long Context (2M tokens)**：可处理长文档、长代码库、研究型内容而不丢失上下文。
|
||||
3. **Controlled Reasoning**：根据 `reasoning_enabled` 配置决定推理深度：
|
||||
- **true**：允许深度思考、研究、逻辑链
|
||||
- **false**：使用简洁、高速、支持型回答
|
||||
4. **Real-World Use Case Optimization**：特别适用于技术支持、调试、研究、大型代码理解、系统架构分析。
|
||||
5. **安全与事实性优先**：对事实错误零容忍；不清楚时应明确说明。
|
||||
|
||||
# Thinking Protocol（思维协议）
|
||||
在回答前你必须执行以下内部流程（用户仅看到摘要）：
|
||||
1. **意图分析**：识别显性与隐性需求
|
||||
2. **上下文吸收**：使用 2M 上下文能力读取相关内容
|
||||
3. **方案构建**：必要时通过工具解决复杂任务
|
||||
4. **逻辑校验**：检查一致性、事实性、安全性
|
||||
5. **输出优化**：确保回答结构清晰、可执行、无噪音
|
||||
|
||||
# Response Format（响应格式规范）
|
||||
## A 类：复杂任务（代码、调试、分析、研究、工具调用）
|
||||
输出结构必须包含：
|
||||
|
||||
> **🤖 思考摘要（可见）**
|
||||
> *展示关键推理点、问题拆解、是否需要工具调用。*
|
||||
|
||||
> **📘 详细解答**
|
||||
> *提供最终答案、步骤、分析或代码。所有代码必须可运行并附注释。*
|
||||
|
||||
> **🛠 工具策略（如适用）**
|
||||
> *如果需要调用工具，请明确指出你的调用目的与预期结果。*
|
||||
|
||||
> **⚡ 延伸建议**
|
||||
> *给出进一步改进、潜在风险或扩展方向。*
|
||||
|
||||
---
|
||||
|
||||
## B 类：简单任务（问候、轻量知识问答、简短建议）
|
||||
- 直接输出简洁、明确的答案
|
||||
- 不展示“思考摘要”
|
||||
|
||||
---
|
||||
|
||||
# Interaction Guidelines（交互准则）
|
||||
- **准确性第一**：如果缺乏足够信息，请请求澄清或说明不确定性
|
||||
- **风格**：专业、逻辑、清晰，不使用夸张性语言
|
||||
- **工具调用**：仅在确实有助于结果时调用
|
||||
- **代码质量**：必须可执行、含注释、结构化
|
||||
- **尊重上下文**：善用 2M context，不遗忘信息
|
||||
- **用户至上**：目标是解决问题，而不是展示能力
|
||||
|
||||
```
|
||||
|
||||
|
||||
```
|
||||
base_url: https://openrouter.ai/api/v1
|
||||
api_key: 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
|
||||
|
||||
text_generation:
|
||||
model_id: x-ai/grok-4.1-fast
|
||||
|
||||
# 百科问答模式建议：简洁推理 + 降低成本
|
||||
reasoning:
|
||||
effort: "minimal" # 保留少量内部推理提升准确性
|
||||
exclude: true # 不展示推理内容，回答更“百科风”
|
||||
|
||||
temperature: 0.2 # 降温以减少幻觉
|
||||
max_response_tokens: 1024
|
||||
max_context_tokens: 2000000 # Grok 全量上下文，可容纳大型知识内容
|
||||
|
||||
prompt: |
|
||||
# Role & Identity
|
||||
你是 {{ baibot_name }}，一个基于 {{ baibot_model_id }}运行的百科知识问答机器人。
|
||||
职责是提供：**准确、权威、可验证** 的知识性回答。
|
||||
当前会话启动时间：{{ baibot_conversation_start_time_utc }}。
|
||||
|
||||
# Core Capabilities（百科问答优化）
|
||||
1. **事实性优先**：必须确保回答可验证，杜绝编造。
|
||||
2. **知识覆盖广**：历史、科技、文化、地理、生物、工程、生活常识等都能回答。
|
||||
3. **解释简洁清晰**：像百科一样用客观语言描述，不夸张，不情绪化。
|
||||
4. **引用型表述**：如知识存在争议，应说明“在主流观点中…”。
|
||||
5. **安全稳妥**：避免医学诊断、金融投资、法律判断等高风险输出。
|
||||
|
||||
# Response Format（回答格式）
|
||||
## 简单知识问答 / 百科问答（默认）
|
||||
- 直接输出明确、准确的答案。
|
||||
- 信息按分点或短段落组织，易读易理解。
|
||||
|
||||
## 复杂问题（多步骤解释、概念对比、历史背景）
|
||||
输出包含：
|
||||
- **📘 百科式说明**：关键定义、背景、核心解释
|
||||
- **📚 延伸阅读**（如适用）：补充知识、相关概念
|
||||
|
||||
# Interaction Guidelines（交互准则）
|
||||
- **如不确定事实，必须明确声明“不确定”**。
|
||||
- 不讨论阴谋论、不可靠数据源、不严谨的统计。
|
||||
- 避免提供专业医学、法律、投资建议。
|
||||
- 保持中立、客观、权威的语气。
|
||||
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
```
|
||||
base_url: "https://zenmux.ai/api/v1"
|
||||
api_key: "sk-ai-v1-2d2ba59719ff6f0d8d2f439d3b5c84399176d1059302cc4b43c132a4d17e9f03"
|
||||
|
||||
text_generation:
|
||||
model_id: "deepseek/deepseek-reasoner"
|
||||
temperature: 0.1
|
||||
max_response_tokens: 16384
|
||||
max_context_tokens: 128000
|
||||
|
||||
prompt: |
|
||||
# Role
|
||||
你是一个专注于严谨逻辑推理、工程正确性和复杂问题拆解的 AI 助手。
|
||||
|
||||
你的核心目标是：
|
||||
- 给出结论正确、可执行、可复查的答案
|
||||
- 在内部进行充分推理，但不显式暴露完整思维链
|
||||
|
||||
# Reasoning Policy
|
||||
- 对复杂问题进行深度推理（内部完成）
|
||||
- 输出时仅提供：
|
||||
- 明确结论
|
||||
- 关键步骤或必要的简化推理说明
|
||||
- 可验证的事实与假设
|
||||
- 不输出逐 token 的思维链
|
||||
|
||||
# Engineering Standards
|
||||
- 所有代码必须可直接运行，包含必要注释与错误处理
|
||||
- 架构或配置建议必须说明原因
|
||||
- 对不确定性必须明确标注
|
||||
|
||||
# Style
|
||||
- 专业、冷静、工程师视角
|
||||
- 少废话，高密度信息
|
||||
|
||||
|
||||
```
|
||||
@@ -0,0 +1,5 @@
|
||||
|
||||
emb:
|
||||
```
|
||||
634442642d294d5cb1b83f5d3790bd98.VH4nn223ldRdyyi_Fuk6MpWz
|
||||
```
|
||||
@@ -0,0 +1,17 @@
|
||||
|
||||
## Key
|
||||
vscode:
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
matrix-bot
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
local rag:
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
|
||||
key
|
||||
```
|
||||
sk-scalJeWNKxWMePXVwiGVnCMjrDpeSkCFxyowSSYp7C9yDpFqX3wY6zg9N7ovJ0MR
|
||||
```
|
||||
@@ -0,0 +1,25 @@
|
||||
|
||||
|
||||
coder ：
|
||||
```
|
||||
sk-ai-v1-875cd41da6e117609e850e4c594d0116f2e128bee9bf6890eb6a48fe23e69764
|
||||
```
|
||||
|
||||
url:
|
||||
```
|
||||
https://zenmux.ai/api/v1
|
||||
```
|
||||
|
||||
```
|
||||
https://zenmux.ai/api/anthropic
|
||||
```
|
||||
|
||||
```
|
||||
https://zenmux.ai/api/vertex-ai
|
||||
```
|
||||
|
||||
obsidian:
|
||||
```
|
||||
sk-ai-v1-82f1a2df15721ca5d5afc633842b91719fea95c6c449cbb78db0dd03f7ed1aa2
|
||||
```
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
Code:
|
||||
```
|
||||
32f3aa3e5c3848fbad264e83b848b226.BVXajLMpbRPaHfv7
|
||||
```
|
||||
@@ -0,0 +1,5 @@
|
||||
|
||||
code token:
|
||||
```
|
||||
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
|
||||
```
|
||||
@@ -0,0 +1,132 @@
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 📘 LiteLLM 配置指南：NewCli (AWS/Anthropic Proxy)
|
||||
|
||||
版本日期: 2025-12-26
|
||||
|
||||
适用场景: 对接自定义 Anthropic 代理（NewCli），解决路径拼接 (404)、参数不兼容 (400) 及防火墙拦截 (403) 问题。
|
||||
|
||||
## 1. 核心参数规范 (Critical Specs)
|
||||
|
||||
无论使用 UI 还是 YAML，必须严格遵守以下三条铁律：
|
||||
|
||||
1. **Provider (提供商)**: 必须选 `Anthropic`。
|
||||
|
||||
- _原因_: 让 LiteLLM 自动处理 `/v1/messages` 路径拼接和 JSON 格式转换。
|
||||
|
||||
2. **Base URL (基准地址)**: `https://code.newcli.com/claude/aws`
|
||||
|
||||
- > [!WARNING] 警告
|
||||
|
||||
- > **严禁**在末尾加 `/v1`。LiteLLM 会自动追加，加了会导致双重路径 (`/v1/v1`) 报 **404**。
|
||||
|
||||
3. **Model ID (模型名)**: `claude-sonnet-4-5`
|
||||
|
||||
- _原因_: 代理商白名单仅支持此 ID。
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 2. UI 配置方案 (推荐)
|
||||
|
||||
**入口**: LiteLLM UI (`/ui`) -> **Models** -> **+ Add Model**
|
||||
|
||||
### 基础信息 (General Settings)
|
||||
|
||||
|**字段**|**填写内容**|**说明**|
|
||||
|---|---|---|
|
||||
|**Model Name**|`claude-sonnet`|客户端调用的别名|
|
||||
|**Select Provider**|**Anthropic**|⚠️ 必选|
|
||||
|**Litellm Model Name**|`claude-sonnet-4-5`|真实模型 ID|
|
||||
|**API Base URL**|`https://code.newcli.com/claude/aws`|⚠️ 末尾无 `/v1`|
|
||||
|**API Key**|`sk-ant-oat01...`|填入完整 Key|
|
||||
|
||||
### 高级参数 (LiteLLM Params / Metadata)
|
||||
|
||||
> [!TIP] 关键步骤
|
||||
>
|
||||
> 在 JSON 输入框填入以下内容，用于解决参数兼容性和防火墙拦截。
|
||||
|
||||
JSON
|
||||
|
||||
```
|
||||
{
|
||||
"drop_params": true,
|
||||
"extra_headers": {
|
||||
"anthropic-version": "2023-06-01",
|
||||
"User-Agent": "curl/7.68.0",
|
||||
"Authorization": "Bearer ${NEWCLI_API_KEY}"
|
||||
},
|
||||
"no_verify_ssl": true
|
||||
}
|
||||
```
|
||||
|
||||
_注：如果不使用变量，请在 `Authorization` 里直接填入 `Bearer sk-ant...`_
|
||||
|
||||
---
|
||||
|
||||
## 3. YAML 文件配置方案 (IaC)
|
||||
|
||||
适用于 `docker-compose` 挂载配置。
|
||||
|
||||
YAML
|
||||
|
||||
```
|
||||
model_list:
|
||||
- model_name: claude-sonnet
|
||||
litellm_params:
|
||||
model: anthropic/claude-sonnet-4-5
|
||||
# ⚠️ 重点：Base URL 不带 /v1
|
||||
api_base: https://code.newcli.com/claude/aws
|
||||
# 建议使用环境变量
|
||||
api_key: os.environ/NEWCLI_API_KEY
|
||||
extra_headers:
|
||||
anthropic-version: "2023-06-01"
|
||||
# 伪装 UA 防拦截
|
||||
User-Agent: "curl/7.68.0"
|
||||
# 强制 Bearer 鉴权 (可选，视代理商严格程度)
|
||||
Authorization: "Bearer ${NEWCLI_API_KEY}"
|
||||
|
||||
general_settings:
|
||||
master_key: sk-1234
|
||||
database_url: postgresql://litellm:litellm@litellm-postgres:5432/litellm
|
||||
|
||||
litellm_settings:
|
||||
# ⚠️ 核心修复：丢弃不兼容参数（如 user, frequency_penalty），解决 400 错误
|
||||
drop_params: true
|
||||
set_verbose: true
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. 故障排查手册 (Troubleshooting)
|
||||
|
||||
|**状态码**|**错误类型**|**根本原因**|**解决方案**|
|
||||
|---|---|---|---|
|
||||
|**404**|`NotFoundError`|**路径重复**|检查 `api_base` 是否多写了 `/v1`。应该让 LiteLLM 自动拼接。|
|
||||
|**400**|`BadRequest`|**参数冗余**|LiteLLM 传了 OpenAI 专有参数给 Anthropic。需开启 `drop_params: true`。|
|
||||
|**403**|`Forbidden`|**WAF 拦截**|缺少 User-Agent 伪装。需在 header 添加 `"User-Agent": "curl/..."`。|
|
||||
|**401**|`AuthError`|**鉴权失败**|Key 错误或格式不对。尝试在 `extra_headers` 强制注入 `Authorization: Bearer <key>`。|
|
||||
|
||||
---
|
||||
|
||||
## 5. 客户端调用示例
|
||||
|
||||
验证配置是否成功的标准命令（访问 LiteLLM 端口）：
|
||||
|
||||
Bash
|
||||
|
||||
```
|
||||
curl -X POST http://localhost:4000/v1/chat/completions \
|
||||
-H "Authorization: Bearer sk-1234" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"model": "claude-sonnet",
|
||||
"messages": [
|
||||
{ "role": "user", "content": "Config Test: OK?" }
|
||||
]
|
||||
}'
|
||||
```
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
|
||||
|
||||
context7 mcp key:
|
||||
```
|
||||
ctx7sk-92c2c98e-817e-41d4-bb85-94824444e2bf
|
||||
```
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
|
||||
compose.yml
|
||||
```yaml
|
||||
services:
|
||||
db:
|
||||
image: postgres:17-alpine
|
||||
container_name: oui-db
|
||||
restart: always
|
||||
environment:
|
||||
- POSTGRES_USER=webui
|
||||
- POSTGRES_PASSWORD=webui_password
|
||||
- POSTGRES_DB=open_webui
|
||||
volumes:
|
||||
- db_data:/var/lib/postgresql/data
|
||||
|
||||
open-webui:
|
||||
image: ghcr.io/open-webui/open-webui:main
|
||||
container_name: oui
|
||||
restart: always
|
||||
ports:
|
||||
- "3000:8080"
|
||||
depends_on:
|
||||
- db
|
||||
extra_hosts:
|
||||
- "host.docker.internal:host-gateway"
|
||||
environment:
|
||||
- 'DATABASE_URL=postgresql://webui:webui_password@db:5432/open_webui'
|
||||
- 'OPENAI_API_BASE_URL=http://host.docker.internal:4000/v1'
|
||||
- 'OPENAI_API_KEY=sk-1234'
|
||||
- 'WEBUI_SECRET_KEY=super_secret_key'
|
||||
volumes:
|
||||
- oui_data:/app/data
|
||||
|
||||
volumes:
|
||||
db_data:
|
||||
oui_data:
|
||||
```
|
||||
@@ -0,0 +1,5 @@
|
||||
|
||||
api key
|
||||
```
|
||||
xai-FDgOu9cZhAkeEBGnkFp61gyTIeqNmWuJ8CLABHIkqTUR1RYzm08hlXabnCTBrj91ee0pYjk0ZWtmRjhS
|
||||
```
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 275 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.0 KiB |
@@ -0,0 +1,21 @@
|
||||
账号：
|
||||
18813973711@1826109533440870.onaliyun.com
|
||||
密码：
|
||||
Jinke@202403
|
||||
|
||||
|
||||
服务器：
|
||||
root
|
||||
Passw0rd
|
||||
|
||||
|
||||
nginx:
|
||||
|
||||
```nginx
|
||||
location /jsc/ {
|
||||
proxy_set_header X-Forwarded-Host $host;
|
||||
proxy_set_header X-Forwarded-Server $host;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_pass http://172.16.0.13:8082/;
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,193 @@
|
||||
|
||||
|
||||
130.120.3.75:
|
||||
|
||||
```bash
|
||||
cat /etc/redhat-release
|
||||
CentOS Linux release 7.5.1804 (Core)
|
||||
```
|
||||
|
||||
|
||||
download :
|
||||
```url
|
||||
https://download.dameng.com/eco/adapter/DM8/202405/dm8_20240408_x86_rh7_64_ent_8.1.3.140.zip
|
||||
```
|
||||
|
||||
|
||||
create user:
|
||||
```bash
|
||||
sudo groupadd dinstall
|
||||
sudo useradd -g dinstall -m -d /home/dmdba -s /bin/bash dmdba
|
||||
```
|
||||
|
||||
|
||||
disable selinux
|
||||
```bash
|
||||
sudo vim /etc/selinux/config
|
||||
```
|
||||
|
||||
limit
|
||||
```
|
||||
sudo vim /etc/security/limits.d/dmdba.conf
|
||||
dmdba soft nofile 65536
|
||||
dmdba hard nofile 65536
|
||||
dmdba soft nproc 4096
|
||||
dmdba hard nproc 63653
|
||||
dmdba soft core unlimited
|
||||
dmdba hard core unlimited
|
||||
|
||||
|
||||
```
|
||||
|
||||
install
|
||||
```bash
|
||||
|
||||
sudo mkdir -p /opt/db/dm
|
||||
|
||||
sudo chown -R dmdba:dinstall /opt/db/dm
|
||||
|
||||
sudo chmod -R 775 /opt/db/dm
|
||||
|
||||
su - dmdba
|
||||
|
||||
cd /opt/db/dm
|
||||
unzip dm8_20240408_x86_rh7_64_ent_8.1.3.140.zip
|
||||
Archive: dm8_20240408_x86_rh7_64_ent_8.1.3.140.zip
|
||||
inflating: dm8_20240408_x86_rh7_64.iso
|
||||
inflating: dm8_20240408_x86_rh7_64.iso_SHA256.txt
|
||||
|
||||
sudo mkdir /mnt/iso
|
||||
sudo mount -o loop /opt/db/dm/dm8_20240408_x86_rh7_64.iso /mnt/iso
|
||||
su - dmdba
|
||||
./DMInstall.bin -i
|
||||
Installer Language:
|
||||
[1]: 简体中文
|
||||
[2]: English
|
||||
Please select the installer's language [2]:
|
||||
Extract install files.........
|
||||
Welcome to DM DBMS Installer
|
||||
|
||||
Whether to input the path of Key File? (Y/y:Yes N/n:No) [Y/y]:n
|
||||
|
||||
Whether to Set The TimeZone? (Y/y:Yes N/n:No) [Y/y]:y
|
||||
TimeZone:
|
||||
[ 1]: (GTM-12:00) West Date Line
|
||||
[ 2]: (GTM-11:00) Samoa
|
||||
[ 3]: (GTM-10:00) Hawaii
|
||||
[ 4]: (GTM-09:00) Alaska
|
||||
[ 5]: (GTM-08:00) Pacific(America and Canada)
|
||||
[ 6]: (GTM-07:00) Arizona
|
||||
[ 7]: (GTM-06:00) Central(America and Canada)
|
||||
[ 8]: (GTM-05:00) East(America and Canada)
|
||||
[ 9]: (GTM-04:00) Atlantic(America and Canada)
|
||||
[10]: (GTM-03:00) Brasilia
|
||||
[11]: (GTM-02:00) Middle Atlantic
|
||||
[12]: (GTM-01:00) Azores
|
||||
[13]: (GTM) Greenwich Mean Time
|
||||
[14]: (GTM+01:00) Sarajevo
|
||||
[15]: (GTM+02:00) Cairo
|
||||
[16]: (GTM+03:00) Moscow
|
||||
[17]: (GTM+04:00) AbuDhabi
|
||||
[18]: (GTM+05:00) Islamabad
|
||||
[19]: (GTM+06:00) Dakar
|
||||
[20]: (GTM+07:00) BangKok,Hanoi
|
||||
[21]: (GTM+08:00) China
|
||||
[22]: (GTM+09:00) Seoul
|
||||
[23]: (GTM+10:00) Guam
|
||||
[24]: (GTM+11:00) Solomon
|
||||
[25]: (GTM+12:00) Fiji
|
||||
[26]: (GTM+13:00) Nukualofa
|
||||
[27]: (GTM+14:00) Kiribati
|
||||
Please Select the TimeZone [9]:21
|
||||
|
||||
Installation Type:
|
||||
1 Typical
|
||||
2 Server
|
||||
3 Client
|
||||
4 Custom
|
||||
Please Input the number of the Installation Type [1 Typical]:1
|
||||
Require Space: 2310M
|
||||
|
||||
Please Input the install path [/home/dmdba/dmdbms]:/opt/db/dm/dmdbms
|
||||
Available Space:32G
|
||||
Please Confirm the install path(/opt/db/dm/dmdbms)? (Y/y:Yes N/n:No) [Y/y]:y
|
||||
|
||||
Pre-Installation Summary
|
||||
Installation Location: /opt/db/dm/dmdbms
|
||||
Require Space: 2310M
|
||||
Available Space: 32G
|
||||
Version Information:
|
||||
Expire Date:
|
||||
Installation Type: Typical
|
||||
Confirm to Install? (Y/y:Yes N/n:No):y
|
||||
2024-06-28 04:55:28
|
||||
[INFO] Installing DM DBMS...
|
||||
2024-06-28 04:55:28
|
||||
[INFO] Installing BASE Module...
|
||||
2024-06-28 04:55:38
|
||||
[INFO] Installing SERVER Module...
|
||||
2024-06-28 04:55:41
|
||||
[INFO] Installing CLIENT Module...
|
||||
2024-06-28 04:55:46
|
||||
[INFO] Installing DRIVERS Module...
|
||||
2024-06-28 04:55:50
|
||||
[INFO] Installing MANUAL Module...
|
||||
2024-06-28 04:55:51
|
||||
[INFO] Installing SERVICE Module...
|
||||
2024-06-28 04:55:51
|
||||
[INFO] Move log file to log directory.
|
||||
2024-06-28 04:55:52
|
||||
[INFO] Installed DM DBMS completely.
|
||||
|
||||
Please execute the commands by root:
|
||||
/opt/db/dm/dmdbms/script/root/root_installer.sh
|
||||
|
||||
End
|
||||
|
||||
[dmdba@localhost iso]$ su -
|
||||
/opt/db/dm/dmdbms/script/root/root_installer.sh
|
||||
Move /opt/db/dm/dmdbms/bin/dm_svc.conf to /etc
|
||||
Create the DmAPService service
|
||||
Created symlink from /etc/systemd/system/multi-user.target.wants/DmAPService.service to /usr/lib/systemd/system/DmAPService.service.
|
||||
Finished to create the service (DmAPService)
|
||||
Start the DmAPService service
|
||||
|
||||
```
|
||||
|
||||
init db
|
||||
```bash
|
||||
cd /opt/db/dm/dmdbms/bin
|
||||
|
||||
./dminit PATH=/opt/db/dm/dmdbms/data DB_NAME=DMDB INSTANCE_NAME=DMDW PORT_NUM=5236
|
||||
initdb V8
|
||||
db version: 0x7000c
|
||||
file dm.key not found, use default license!
|
||||
License will expire on 2025-03-21
|
||||
Normal of FAST
|
||||
Normal of DEFAULT
|
||||
Normal of RECYCLE
|
||||
Normal of KEEP
|
||||
Normal of ROLL
|
||||
|
||||
log file path: /opt/db/dm/dmdbms/data/DMDB/DMDB01.log
|
||||
|
||||
|
||||
log file path: /opt/db/dm/dmdbms/data/DMDB/DMDB02.log
|
||||
|
||||
write to dir [/opt/db/dm/dmdbms/data/DMDB].
|
||||
create dm database success. 2024-06-28 05:18:08
|
||||
|
||||
cd /opt/db/dm/dmdbms/script/root
|
||||
su
|
||||
Password:
|
||||
[root@localhost root]# ls
|
||||
dm_service_installer.sh dm_service_uninstaller.sh root_installer.sh
|
||||
[root@localhost root]# pwd
|
||||
/opt/db/dm/dmdbms/script/root
|
||||
[root@localhost root]# ./dm_service_installer.sh -t dmserver -dm_ini /opt/db/dm/dmdbms/data/DMDB/dm.ini -p DMDW
|
||||
Created symlink from /etc/systemd/system/multi-user.target.wants/DmServiceDMDW.service to /usr/lib/systemd/system/DmServiceDMDW.service.
|
||||
Finished to create the service (DmServiceDMDW)
|
||||
|
||||
|
||||
```
|
||||
|
||||
@@ -0,0 +1,63 @@
|
||||
BEGIN
|
||||
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
|
||||
retention => 7 * 24 * 60, -- Retain snapshots for 7 days
|
||||
interval => 60 -- Collect snapshot every 60 minutes
|
||||
);
|
||||
END;
|
||||
/
|
||||
|
||||
|
||||
BEGIN
|
||||
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings(
|
||||
retention => 7 * 24 * 60,
|
||||
interval => 60
|
||||
);
|
||||
END;
|
||||
/
|
||||
|
||||
|
||||
EXEC DBMS_STATS.alter_stats_history_retention(RETENTION => 7);
|
||||
|
||||
4gu1ln
|
||||
|
||||
|
||||
SELECT table_name,
|
||||
bytes / 1024 / 1024 AS size_mb,
|
||||
blocks,
|
||||
extents
|
||||
FROM dba_segments
|
||||
WHERE segment_type = 'TABLE'
|
||||
AND tablespace_name = 'USERS'
|
||||
ORDER BY bytes DESC;
|
||||
|
||||
SELECT segment_name AS table_name,
|
||||
bytes / 1024 / 1024 AS size_mb,
|
||||
blocks,
|
||||
extents
|
||||
FROM dba_segments
|
||||
WHERE segment_type = 'TABLE'
|
||||
AND tablespace_name = 'USERS'
|
||||
ORDER BY bytes DESC;
|
||||
|
||||
|
||||
ALTER TABLE enforce_center.SHR_DATA_SWITCH_LOGS ENABLE ROW MOVEMENT;
|
||||
ALTER TABLE enforce_center.SHR_DATA_SWITCH_LOGS SHRINK SPACE;
|
||||
|
||||
|
||||
|
||||
SELECT segment_name AS index_name,
|
||||
owner,
|
||||
bytes / 1024 / 1024 AS size_mb,
|
||||
blocks,
|
||||
extents
|
||||
FROM dba_segments
|
||||
WHERE segment_type = 'INDEX'
|
||||
AND tablespace_name = 'ENFORCE_CENTER'
|
||||
ORDER BY size_mb DESC;
|
||||
|
||||
|
||||
ALTER INDEX ENFORCE_CENTER.PERSON_INDEX REBUILD;
|
||||
|
||||
|
||||
|
||||
DROP TABLE ENFORCE_CENTER.PATROL_DOC_copy1 PURGE;
|
||||
@@ -0,0 +1,9 @@
|
||||
|
||||
```sql
|
||||
ALTER SESSION SET CURRENT_SCHEMA=enforce_center;
|
||||
|
||||
ALTER SESSION SET sql_trace = TRUE;
|
||||
|
||||
|
||||
```
|
||||
|
||||
@@ -0,0 +1,131 @@
|
||||
|
||||
|
||||
To integrate Forgejo running in a Docker container with the host's SSH server, follow these steps:
|
||||
|
||||
### Step 1: Disable Forgejo's Internal SSH Server
|
||||
In your `docker-compose.yml` file, add the environment variable to disable Forgejo's internal SSH server:
|
||||
|
||||
```yaml
|
||||
environment:
|
||||
- FORGEJO__server__START_SSH_SERVER=false
|
||||
```
|
||||
|
||||
### Step 2: Configure the Host SSH Server
|
||||
Add a dedicated user for Forgejo (e.g., `git`) on your host:
|
||||
|
||||
```bash
|
||||
sudo adduser --disabled-password --gecos 'Forgejo' git
|
||||
```
|
||||
|
||||
Update the SSH configuration in `/etc/ssh/sshd_config`:
|
||||
|
||||
```bash
|
||||
Match User git
|
||||
AllowTcpForwarding yes
|
||||
X11Forwarding no
|
||||
PermitTunnel no
|
||||
AllowAgentForwarding no
|
||||
ForceCommand docker exec -i forgejo /app/gitea/gitea serv key-$SSH_ORIGINAL_COMMAND
|
||||
```
|
||||
|
||||
Restart the SSH server:
|
||||
|
||||
```bash
|
||||
sudo systemctl restart sshd
|
||||
```
|
||||
|
||||
### Step 3: Update Forgejo Configuration
|
||||
Ensure that Forgejo's SSH domain and port in the configuration match your host's SSH settings. You can do this in the Forgejo web interface or by modifying the `app.ini` file within the container.
|
||||
|
||||
This setup allows Forgejo to use the host's SSH server for Git operations while running in a Docker container.
|
||||
|
||||
|
||||
|
||||
create user
|
||||
```bash
|
||||
docker exec forgejo forgejo admin user create --username fengzhiqiang --password admingzzn --email fengzhq@it2000.com.cn --admin
|
||||
```
|
||||
|
||||
|
||||
email
|
||||
```
|
||||
HOST = smtp.exmail.qq.com:465
|
||||
FROM = server@it2000.com.cn
|
||||
USER = server@it2000.com.cn
|
||||
PASSWD = Gzzn1234
|
||||
|
||||
```
|
||||
|
||||
|
||||
freeipa:
|
||||
add user forgejo/forgejopass for bind
|
||||
|
||||
|
||||
To add FreeIPA LDAP as an authentication source in Forgejo, follow these steps:
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. **FreeIPA Server**: Ensure you have a FreeIPA server set up and running.
|
||||
2. **Forgejo Installation**: Have Forgejo installed and accessible.
|
||||
|
||||
## Configuration Steps
|
||||
|
||||
### 1. Create a Bind Account in FreeIPA
|
||||
|
||||
- **Create a gitea.ldif file** on the FreeIPA server, replacing `dc=example,dc=com` with your DN, and provide an appropriately secure password:
|
||||
|
||||
```ldif
|
||||
dn: uid=gitea,cn=sysaccounts,cn=etc,dc=example,dc=com
|
||||
changetype: add
|
||||
objectclass: account
|
||||
objectclass: simplesecurityobject
|
||||
uid: gitea
|
||||
userPassword: secure password
|
||||
passwordExpirationTime: 20380119031407Z
|
||||
nsIdleTimeout: 0
|
||||
```
|
||||
|
||||
- **Import the LDIF** (change localhost to an IPA server if needed). Provide the Directory Manager password when prompted:
|
||||
|
||||
```bash
|
||||
ldapmodify -h localhost -p 389 -x -D "cn=Directory Manager" -W -f gitea.ldif
|
||||
```
|
||||
|
||||
- **Add an IPA group for gitea_users**:
|
||||
|
||||
```bash
|
||||
ipa group-add --desc="Gitea Users" gitea_users
|
||||
```
|
||||
|
||||
### 2. Configure Forgejo
|
||||
|
||||
- **Log in to Forgejo as an Administrator** and navigate to Admin Panel > Authentication.
|
||||
- **Click on "Add New Source"** and select "LDAP (via BindDN)".
|
||||
- **Fill in the following fields**, changing all where appropriate:
|
||||
|
||||
- **Authorization Name**: FreeIPA
|
||||
- **Host**: `ldap://<your-freeipa-server>`
|
||||
- **Port**: 389
|
||||
- **Bind DN**: `uid=gitea,cn=sysaccounts,cn=etc,dc=example,dc=com`
|
||||
- **Bind Password**: secure password
|
||||
- **User Search Base**: `ou=Users,dc=example,dc=com`
|
||||
- **User Filter**: `(&(objectClass=posixAccount)(uid=%s))`
|
||||
- **Admin Filter**: `(memberOf=cn=gitea_users,cn=groups,cn=accounts,dc=example,dc=com)`
|
||||
- **Username Attribute**: uid
|
||||
- **First Name Attribute**: givenName
|
||||
- **Surname Attribute**: sn
|
||||
- **Email Attribute**: mail
|
||||
|
||||
- **Save the changes** and test the authentication by logging out and trying to log in with a FreeIPA user account.
|
||||
|
||||
By following these steps, you can successfully integrate FreeIPA LDAP as an authentication source in Forgejo, allowing users to log in with their FreeIPA credentials.
|
||||
|
||||
Citations:
|
||||
[1] https://www.reddit.com/r/FreeIPA/comments/1ax8te1/can_i_use_an_existing_ldap_server_as_a_source_of/
|
||||
[2] https://github.com/freeipa/freeipa
|
||||
[3] https://freeipa.readthedocs.io/en/latest/designs/external-idp/external-idp.html
|
||||
[4] https://fossies.org/linux/forgejo/docs/content/usage/authentication.en-us.md
|
||||
[5] https://forgejo.org/docs/latest/admin/config-cheat-sheet/
|
||||
[6] https://huijzer.xyz/posts/forgejo-setup/
|
||||
[7] https://forum.yunohost.org/t/how-to-authenticate-to-foregjo-over-https/25444
|
||||
[8] https://forgejo.org/docs/latest/admin/email-setup/
|
||||
@@ -0,0 +1,11 @@
|
||||
token:
|
||||
g1mYHokq7pEGgP_z4_VU
|
||||
|
||||
http --pretty format "https://gitlab.int.it2000.com.cn/api/v4/projects/?simple=yes&per_page=1000&page=1" > project.json
|
||||
|
||||
curl --header "PRIVATE-TOKEN:g1mYHokq7pEGgP_z4_VU" "https://gitlab.int.it2000.com.cn/api/v4/projects/?simple=yes&private=true&per_page=1000&page=1" | jq > project.json
|
||||
|
||||
https://tableconvert.com/json-to-excel
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
### Notes
|
||||
```dataview
|
||||
table file.ctime as Date from "300-resources/Development"
|
||||
sort file.name
|
||||
```
|
||||
@@ -0,0 +1,31 @@
|
||||
|
||||
|
||||
install:
|
||||
|
||||
```bash
|
||||
|
||||
sudo ipa-server-install --domain=int.it2000.com.cn \
|
||||
--ds-password=admingzzn \
|
||||
--admin-password=admingzzn \
|
||||
--hostname=ipa.int.it2000.com.cn \
|
||||
--ip-address=10.100.100.2 \
|
||||
--setup-dns
|
||||
```
|
||||
|
||||
|
||||
coolpit ssl:
|
||||
|
||||
```bash
|
||||
ipa-getcert request -f /etc/cockpit/ws-certs.d/$(hostname -f).cert -k /etc/cockpit/ws-certs.d/$(hostname -f).key -D $(hostname -f) -K host/$(hostname -f) -m 0640 -o root:cockpit-ws -O root:root -M 0644
|
||||
```
|
||||
|
||||
|
||||
```bash
|
||||
ipa-getcert list
|
||||
```
|
||||
|
||||
|
||||
change user password:
|
||||
```bash
|
||||
ipa user-mod (user) --password
|
||||
```
|
||||
@@ -0,0 +1,8 @@
|
||||
|
||||
|
||||
https://121.8.227.182:8988/
|
||||
|
||||
|
||||
admin
|
||||
|
||||
u3fPP*-N?pYGYLZT
|
||||
@@ -0,0 +1,17 @@
|
||||
|
||||
|
||||
# Rustdesk
|
||||
## GZZN OFFICE
|
||||
|
||||
### win 10 desktop
|
||||
1259681763
|
||||
```
|
||||
w42YyME_y3jVb!qa4X.c
|
||||
```
|
||||
|
||||
### opensuse desktop
|
||||
11 439 584:
|
||||
```
|
||||
uW!g6CU6kteozaHUaJX*
|
||||
```
|
||||
|
||||
+37
@@ -0,0 +1,37 @@
|
||||
Title: "\[Better Developers\] Using 'From X Import Y' in Python"
|
||||
Author: [[Reuven Lerner]]
|
||||
From:
|
||||
|
||||
## Highlights:
|
||||
|
||||
Is a variation on "import" that is commonly used, which looks like this:
|
||||
from X import Y
|
||||
|
||||
The idea is pretty simple: When you say
|
||||
import foobar
|
||||
|
||||
you're creating a variable "foobar" in the current namespace. That variable is a module, whose attributes are the global variables created in the module's file
|
||||
|
||||
Whether you find it aesthetically ugly, or annoying to type, or confusing, or if you just want to put it in the current namespace, you can do that with:
|
||||
from foobar import hello
|
||||
|
||||
Or if you want both of them, you can say
|
||||
from foobar import hello, x
|
||||
|
||||
Once you have done this, the names "hello" and "x" are defined in your current namespace, and you can use them to access the module's attributes
|
||||
|
||||
Note that I keep saying, "the current namespace." That's because "import", like "def", is a way to define a variable. When you use "def", you're both creating a function object and setting a variable (the function name) to point to that function object. And when you use "import", you're both creating a module object, and setting a variable (the module name) to point to that module object.
|
||||
|
||||
But all variables can be global or local -- and modules are no different.
|
||||
|
||||
I should note that while you can use an "import" statement anywhere, it's pretty rare in my experience to have it anywhere but at the global scope
|
||||
|
||||
So: "from-import" loads the entire module, and puts the module in sys.modules. It then creates aliases to the specified names in the local namespace.
|
||||
|
||||
And if you're using "from-import" because you want to save memory, or don't want to load an entire module, that's obviously bad news.
|
||||
|
||||
When you say "from import *", you're saying that it would be totally OK for the module's variables to overwrite the variables that you have defined in the current namespace
|
||||
|
||||
For starters, "from-import" ignores names that start with an underscore (_) character
|
||||
|
||||
If I want, I can also define the variable __all__, a list of strings indicating which names should be exported when you use a wildcard
|
||||
@@ -0,0 +1,4 @@
|
||||
## Highlights:
|
||||
`Mock.patch ` will intercept import statements identified by a string, and return a Mock instance you can preconfigure using the techniques we discussed above.
|
||||
|
||||
we need to supply `Mock.patch ` with a string representing our specific import. We do not want to supply simply `os.getcwd ` since that would patch it for all modules, instead we want to supply the module under test’s import of os , i.e. work.os . When the module is imported patch will work its magic and return a Mock instead.
|
||||
@@ -0,0 +1,3 @@
|
||||
|
||||
|
||||
变量隐藏 [[Scope and Shadowing - Rust By Example]]
|
||||
@@ -0,0 +1,15 @@
|
||||
Fundamental rules for for Universal Naming Convention (UNC),which enable applications to create and process valid names for files and directories, regardless of the file system:
|
||||
|
||||
Following reserved characters:
|
||||
```
|
||||
< (less than)
|
||||
> (greater than)
|
||||
: (colon)
|
||||
" (double quote)
|
||||
/ (forward slash)
|
||||
\ (backslash)
|
||||
| (vertical bar or pipe)
|
||||
? (question mark)
|
||||
* (asterisk)
|
||||
```
|
||||
Use any character in the current code page for a name, including Unicode characters and characters in the extended character set (128–255),
|
||||
@@ -0,0 +1,9 @@
|
||||
```bash
|
||||
|
||||
sudo ipa-server-install --realm=INT.IT2000.COM.CN --domain=int.it2000.com.cn --ds-password=admingzzn --admin-password=admingzzn --hostname=ipa.int.it2000.com.cn --ip-address=10.16.67.98 --setup-dns
|
||||
|
||||
sudo firewall-cmd --add-service={http,https,dns,ntp,freeipa-ldap,freeipa-ldaps} --permanent
|
||||
|
||||
sudo firewall-cmd --reload
|
||||
|
||||
```
|
||||
@@ -0,0 +1,23 @@
|
||||
If your user is called `user` and your host is called you could add these lines to `/etc/sudoers`:
|
||||
|
||||
```
|
||||
user = (root) NOPASSWD: /sbin/shutdown
|
||||
user = (root) NOPASSWD: /sbin/reboot
|
||||
```
|
||||
|
||||
This will allow the user `user` to run the desired commands without entering a password. All other sudoed commands will still require a password.
|
||||
|
||||
The commands specified in the `sudoers` file _must_ be fully qualified (i.e. using the absolute path to the command to run)
|
||||
|
||||
If the command ends with a trailing `/` character and points to a directory, the user will be able to run any command in that directory (but not in any sub-directories therein). In the following example, the user `user` can run any command in the directory `/home/someuser/bin/`:
|
||||
|
||||
```
|
||||
user = (root) NOPASSWD: /home/someuser/bin/
|
||||
```
|
||||
|
||||
As an alternative to editing the `/etc/sudoers` file, you could add the two lines to a new file in `/etc/sudoers.d` e.g. `/etc/sudoers.d/shutdown`. This is an elegant way of separating different changes to the `sudo` rights and also leaves the original `sudoers` file untouched for easier upgrades.
|
||||
|
||||
*visudo can be used to edit those files too, this prevent error that could lock you out of the system*
|
||||
```
|
||||
sudo visudo -f /etc/sudoers.d/shutdown
|
||||
```
|
||||
@@ -0,0 +1,508 @@
|
||||
|
||||
Certainly! I can guide you through the process of using **cfssl** (Cloudflare's PKI toolkit) to generate a self-signed Certificate Authority (CA) and server certificate for your Nacos server. Then, I'll show you how to import the CA certificate into your Spring Boot application's Docker container so that it trusts the Nacos server's certificate.
|
||||
|
||||
This approach provides a robust and manageable way to handle certificates, especially when dealing with multiple services and environments.
|
||||
|
||||
---
|
||||
|
||||
## **Overview**
|
||||
|
||||
1. **Install cfssl and cfssljson**: Set up the cfssl toolkit.
|
||||
2. **Generate a Self-Signed CA Certificate**: Create a root CA using cfssl.
|
||||
3. **Generate a Server Certificate for Nacos Signed by the CA**: Create a certificate for your Nacos server.
|
||||
4. **Configure the Nacos Server to Use the Server Certificate**: Set up Nacos to use the generated certificate.
|
||||
5. **Import the CA Certificate into Your Spring Boot Application's Docker Container**: Ensure your application trusts the Nacos server's certificate.
|
||||
6. **Configure Your Spring Boot Application**: Update settings to communicate with the Nacos server over HTTPS.
|
||||
7. **Test the Setup**: Verify that everything works as expected.
|
||||
|
||||
---
|
||||
|
||||
## **Prerequisites**
|
||||
|
||||
- **cfssl and cfssljson** installed on your system.
|
||||
- **Nacos server** installed and running.
|
||||
- **Docker** installed and configured.
|
||||
- **Spring Boot application** ready to be containerized.
|
||||
|
||||
---
|
||||
|
||||
## **Step 1: Install cfssl and cfssljson**
|
||||
|
||||
First, you need to install **cfssl** and **cfssljson**. These are command-line tools provided by Cloudflare for managing PKI.
|
||||
|
||||
### **1.1. Download the Binaries**
|
||||
|
||||
#### **For Linux:**
|
||||
|
||||
```bash
|
||||
# Download cfssl
|
||||
curl -L -o cfssl https://github.com/cloudflare/cfssl/releases/download/v1.6.3/cfssl_linux-amd64
|
||||
|
||||
# Download cfssljson
|
||||
curl -L -o cfssljson https://github.com/cloudflare/cfssl/releases/download/v1.6.3/cfssljson_linux-amd64
|
||||
```
|
||||
|
||||
#### **For macOS:**
|
||||
|
||||
```bash
|
||||
# Download cfssl
|
||||
curl -L -o cfssl https://github.com/cloudflare/cfssl/releases/download/v1.6.3/cfssl_darwin-amd64
|
||||
|
||||
# Download cfssljson
|
||||
curl -L -o cfssljson https://github.com/cloudflare/cfssl/releases/download/v1.6.3/cfssljson_darwin-amd64
|
||||
```
|
||||
|
||||
### **1.2. Make the Binaries Executable**
|
||||
|
||||
```bash
|
||||
chmod +x cfssl cfssljson
|
||||
```
|
||||
|
||||
### **1.3. Move the Binaries to Your PATH**
|
||||
|
||||
```bash
|
||||
sudo mv cfssl cfssljson /usr/local/bin/
|
||||
```
|
||||
|
||||
Alternatively, you can add the directory containing `cfssl` and `cfssljson` to your `PATH`.
|
||||
|
||||
### **1.4. Verify Installation**
|
||||
|
||||
```bash
|
||||
cfssl version
|
||||
cfssljson -version
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **Step 2: Generate a Self-Signed CA Certificate**
|
||||
|
||||
We'll create a self-signed CA certificate using cfssl.
|
||||
|
||||
### **2.1. Create a CA Configuration File (`ca-config.json`)**
|
||||
|
||||
Create a file named `ca-config.json` with the following content:
|
||||
|
||||
```json
|
||||
{
|
||||
"signing": {
|
||||
"default": {
|
||||
"expiry": "8760h"
|
||||
},
|
||||
"profiles": {
|
||||
"nacos": {
|
||||
"expiry": "87600h",
|
||||
"usages": ["signing", "key encipherment", "server auth", "client auth"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### **2.2. Create a CA Certificate Signing Request (`ca-csr.json`)**
|
||||
|
||||
Create a file named `ca-csr.json` with the following content:
|
||||
|
||||
```json
|
||||
{
|
||||
"CN": "My Root CA",
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 4096
|
||||
},
|
||||
"names": [
|
||||
{
|
||||
"C": "US",
|
||||
"ST": "State",
|
||||
"L": "City",
|
||||
"O": "YourOrganization",
|
||||
"OU": "YourUnit"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### **2.3. Generate the CA Certificate and Key**
|
||||
|
||||
Run the following command:
|
||||
|
||||
```bash
|
||||
cfssl gencert -initca ca-csr.json | cfssljson -bare ca
|
||||
```
|
||||
|
||||
This command generates:
|
||||
|
||||
- `ca.pem`: The CA certificate.
|
||||
- `ca-key.pem`: The CA private key.
|
||||
- `ca.csr`: The CA certificate signing request (not needed further).
|
||||
|
||||
**Note:** Keep `ca-key.pem` secure and do not share it.
|
||||
|
||||
---
|
||||
|
||||
## **Step 3: Generate a Server Certificate for Nacos Signed by the CA**
|
||||
|
||||
### **3.1. Create a Server Certificate Signing Request (`nacos-csr.json`)**
|
||||
|
||||
Create a file named `nacos-csr.json` with the following content:
|
||||
|
||||
```json
|
||||
{
|
||||
"CN": "nacos.example.com",
|
||||
"hosts": [
|
||||
"nacos.example.com",
|
||||
"127.0.0.1",
|
||||
"192.168.1.100"
|
||||
],
|
||||
"key": {
|
||||
"algo": "rsa",
|
||||
"size": 2048
|
||||
},
|
||||
"names": [
|
||||
{
|
||||
"C": "US",
|
||||
"ST": "State",
|
||||
"L": "City",
|
||||
"O": "YourOrganization",
|
||||
"OU": "YourUnit"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- **`CN`**: Common Name. Should match the domain name used to access Nacos.
|
||||
- **`hosts`**: Include all DNS names and IP addresses that will be used to access the Nacos server.
|
||||
- Replace `"nacos.example.com"` and `"192.168.1.100"` with your server's actual domain and IP address.
|
||||
|
||||
### **3.2. Generate the Server Certificate and Key**
|
||||
|
||||
Run the following command:
|
||||
|
||||
```bash
|
||||
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=nacos nacos-csr.json | cfssljson -bare nacos
|
||||
```
|
||||
|
||||
This command generates:
|
||||
|
||||
- `nacos.pem`: The Nacos server certificate.
|
||||
- `nacos-key.pem`: The Nacos server private key.
|
||||
- `nacos.csr`: The Nacos server CSR (not needed further).
|
||||
|
||||
### **3.3. Verify the Certificates**
|
||||
|
||||
You can inspect the server certificate:
|
||||
|
||||
```bash
|
||||
openssl x509 -in nacos.pem -text -noout
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **Step 4: Configure the Nacos Server to Use the Server Certificate**
|
||||
|
||||
Now, configure your Nacos server to use the generated `nacos.pem` and `nacos-key.pem` files.
|
||||
|
||||
### **4.1. Convert the Certificates to PKCS#12 Format (If Necessary)**
|
||||
|
||||
Some servers require certificates in PKCS#12 format.
|
||||
|
||||
```bash
|
||||
openssl pkcs12 -export -in nacos.pem -inkey nacos-key.pem -out nacos.p12 -name nacos -CAfile ca.pem -caname root -password pass:yourpassword
|
||||
```
|
||||
|
||||
- **`nacos.p12`**: The PKCS#12 keystore file.
|
||||
- **`yourpassword`**: Replace with a secure password.
|
||||
|
||||
### **4.2. Configure Nacos to Use SSL**
|
||||
|
||||
#### **Option A: Standalone Nacos (Embedded Tomcat)**
|
||||
|
||||
If you're running Nacos in standalone mode using embedded Tomcat, you can configure SSL in `application.properties` or `application.yml`.
|
||||
|
||||
**In `application.properties`:**
|
||||
|
||||
```properties
|
||||
server.port=8848
|
||||
server.ssl.enabled=true
|
||||
server.ssl.key-store=classpath:nacos.p12
|
||||
server.ssl.key-store-password=yourpassword
|
||||
server.ssl.key-store-type=PKCS12
|
||||
```
|
||||
|
||||
- **Note**: Place `nacos.p12` in the `classpath` (e.g., in the `resources` directory).
|
||||
|
||||
#### **Option B: Nacos with External Tomcat or Nginx**
|
||||
|
||||
If you're using an external server (like Tomcat or Nginx), configure it to use `nacos.pem` and `nacos-key.pem`.
|
||||
|
||||
**Example with Nginx:**
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 443 ssl;
|
||||
server_name nacos.example.com;
|
||||
|
||||
ssl_certificate /path/to/nacos.pem;
|
||||
ssl_certificate_key /path/to/nacos-key.pem;
|
||||
ssl_client_certificate /path/to/ca.pem;
|
||||
ssl_verify_client off; # Change to 'on' if you want to verify client certificates
|
||||
|
||||
location / {
|
||||
proxy_pass http://localhost:8848;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### **4.3. Restart the Nacos Server**
|
||||
|
||||
After configuring SSL, restart your Nacos server to apply the changes.
|
||||
|
||||
---
|
||||
|
||||
## **Step 5: Import the CA Certificate into Your Spring Boot Application's Docker Container**
|
||||
|
||||
Your Spring Boot application needs to trust the CA that signed the Nacos server's certificate. We'll import `ca.pem` into the Java trust store inside your Docker container.
|
||||
|
||||
### **5.1. Convert the CA Certificate to DER Format**
|
||||
|
||||
Java `keytool` requires certificates in DER format.
|
||||
|
||||
```bash
|
||||
openssl x509 -outform der -in ca.pem -out ca.der
|
||||
```
|
||||
|
||||
### **5.2. Update Your Dockerfile**
|
||||
|
||||
Modify your `Dockerfile` to include the CA certificate and import it into the Java trust store.
|
||||
|
||||
#### **Example Dockerfile:**
|
||||
|
||||
```dockerfile
|
||||
# Use an official OpenJDK runtime as a parent image
|
||||
FROM openjdk:17-jdk-slim
|
||||
|
||||
# Set the working directory
|
||||
WORKDIR /app
|
||||
|
||||
# Copy the application's JAR file into the container
|
||||
COPY target/your-application.jar /app/your-application.jar
|
||||
|
||||
# Copy the CA certificate into the container
|
||||
COPY ca.der /tmp/ca.der
|
||||
|
||||
# Import the CA certificate into Java's trust store
|
||||
RUN keytool -importcert \
|
||||
-alias myca \
|
||||
-keystore $JAVA_HOME/lib/security/cacerts \
|
||||
-file /tmp/ca.der \
|
||||
-storepass changeit \
|
||||
-noprompt
|
||||
|
||||
# Clean up the temporary certificate file
|
||||
RUN rm /tmp/ca.der
|
||||
|
||||
# Expose the application port
|
||||
EXPOSE 8080
|
||||
|
||||
# Run the application
|
||||
ENTRYPOINT ["java", "-jar", "/app/your-application.jar"]
|
||||
```
|
||||
|
||||
**Notes:**
|
||||
|
||||
- **`COPY ca.der /tmp/ca.der`**: Ensure `ca.der` is in the same directory as your `Dockerfile`.
|
||||
- **`$JAVA_HOME/lib/security/cacerts`**: Default Java trust store.
|
||||
- **`-storepass changeit`**: Default password for `cacerts`. Use the correct password if it's different.
|
||||
|
||||
### **5.3. Build the Docker Image**
|
||||
|
||||
```bash
|
||||
docker build -t your-application-image .
|
||||
```
|
||||
|
||||
### **5.4. Run the Docker Container**
|
||||
|
||||
```bash
|
||||
docker run -p 8080:8080 your-application-image
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **Step 6: Configure Your Spring Boot Application**
|
||||
|
||||
Ensure your application is configured to communicate with the Nacos server over HTTPS.
|
||||
|
||||
### **6.1. Update Application Properties**
|
||||
|
||||
In your `application.properties` or `application.yml`, update the Nacos server address to use `https` and the correct port.
|
||||
|
||||
**Example (`application.properties`):**
|
||||
|
||||
```properties
|
||||
spring.cloud.nacos.server-addr=https://nacos.example.com:8848
|
||||
spring.cloud.nacos.username=your-username
|
||||
spring.cloud.nacos.password=your-password
|
||||
```
|
||||
|
||||
### **6.2. Disable Hostname Verification (If Necessary)**
|
||||
|
||||
If the hostname verification fails, you may need to disable it (not recommended for production).
|
||||
|
||||
Add the following JVM option:
|
||||
|
||||
```bash
|
||||
-Dcom.sun.net.ssl.checkRevocation=false -Djavax.net.ssl.trustStore=$JAVA_HOME/lib/security/cacerts
|
||||
```
|
||||
|
||||
Alternatively, set up a custom `HostnameVerifier` in your code.
|
||||
|
||||
---
|
||||
|
||||
## **Step 7: Test the Setup**
|
||||
|
||||
After starting your Docker container, test your application to ensure it communicates securely with the Nacos server.
|
||||
|
||||
- **Check Logs**: Look for any SSL-related errors.
|
||||
- **Verify Communication**: Ensure your application can register with Nacos or retrieve configurations.
|
||||
|
||||
---
|
||||
|
||||
## **Additional Considerations**
|
||||
|
||||
### **Using a Custom Trust Store**
|
||||
|
||||
Instead of modifying the default Java trust store (`cacerts`), you can create and use a custom trust store.
|
||||
|
||||
#### **5.2.1. Create a Custom Trust Store**
|
||||
|
||||
```dockerfile
|
||||
# Create a custom trust store and import the CA certificate
|
||||
RUN keytool -importcert \
|
||||
-alias myca \
|
||||
-keystore /app/truststore.jks \
|
||||
-file /tmp/ca.der \
|
||||
-storepass yourtruststorepassword \
|
||||
-noprompt
|
||||
```
|
||||
|
||||
#### **5.2.2. Set JVM Options to Use the Custom Trust Store**
|
||||
|
||||
```dockerfile
|
||||
# Set environment variable for JVM options
|
||||
ENV JAVA_OPTS="-Djavax.net.ssl.trustStore=/app/truststore.jks -Djavax.net.ssl.trustStorePassword=yourtruststorepassword"
|
||||
```
|
||||
|
||||
#### **5.2.3. Update the ENTRYPOINT**
|
||||
|
||||
```dockerfile
|
||||
ENTRYPOINT ["java", "$JAVA_OPTS", "-jar", "/app/your-application.jar"]
|
||||
```
|
||||
|
||||
### **Handling Sensitive Information**
|
||||
|
||||
Avoid hardcoding passwords in your `Dockerfile`. Use build arguments or environment variables.
|
||||
|
||||
#### **Using Build Arguments**
|
||||
|
||||
```dockerfile
|
||||
# Build argument for trust store password
|
||||
ARG TRUSTSTORE_PASS=yourtruststorepassword
|
||||
|
||||
# Use the build argument in the RUN command
|
||||
RUN keytool -importcert \
|
||||
-alias myca \
|
||||
-keystore /app/truststore.jks \
|
||||
-file /tmp/ca.der \
|
||||
-storepass $TRUSTSTORE_PASS \
|
||||
-noprompt
|
||||
|
||||
# Set JVM options
|
||||
ENV JAVA_OPTS="-Djavax.net.ssl.trustStore=/app/truststore.jks -Djavax.net.ssl.trustStorePassword=$TRUSTSTORE_PASS"
|
||||
```
|
||||
|
||||
Build the Docker image with:
|
||||
|
||||
```bash
|
||||
docker build --build-arg TRUSTSTORE_PASS=yourtruststorepassword -t your-application-image .
|
||||
```
|
||||
|
||||
### **Securing Private Keys**
|
||||
|
||||
- **Do Not Include Private Keys in Docker Images**: Ensure that `ca-key.pem` and `nacos-key.pem` are not copied into the Docker image.
|
||||
- **Secure Storage**: Store private keys securely and avoid committing them to version control.
|
||||
|
||||
---
|
||||
|
||||
## **Troubleshooting**
|
||||
|
||||
### **Common Issues and Solutions**
|
||||
|
||||
#### **SSLHandshakeException**
|
||||
|
||||
- **Cause**: The application doesn't trust the Nacos server's certificate.
|
||||
- **Solution**: Ensure the CA certificate is correctly imported into the trust store.
|
||||
|
||||
#### **Hostname Verification Failure**
|
||||
|
||||
- **Cause**: The hostname used to access the Nacos server doesn't match the `CN` or `hosts` in the certificate.
|
||||
- **Solution**:
|
||||
- Ensure the Nacos server's domain matches the `CN` or is included in the `hosts` field.
|
||||
- Use the correct domain or IP address when accessing the server.
|
||||
- As a temporary measure, disable hostname verification (not recommended for production).
|
||||
|
||||
#### **Keytool Not Found**
|
||||
|
||||
- **Cause**: `keytool` is not available in the base Docker image.
|
||||
- **Solution**: Use a JDK-based Docker image (e.g., `openjdk:17-jdk-slim`) instead of a JRE image.
|
||||
|
||||
#### **Incorrect Keystore Password**
|
||||
|
||||
- **Cause**: Wrong `storepass` used when importing the certificate.
|
||||
- **Solution**: Verify the trust store password.
|
||||
|
||||
#### **Certificate Not Found**
|
||||
|
||||
- **Cause**: The certificate file is not correctly copied or the path is incorrect.
|
||||
- **Solution**: Verify the `COPY` command and file paths in the `Dockerfile`.
|
||||
|
||||
### **Testing the Trust Store**
|
||||
|
||||
List the certificates in the trust store to confirm the import:
|
||||
|
||||
```dockerfile
|
||||
RUN keytool -list -keystore $JAVA_HOME/lib/security/cacerts -storepass changeit
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## **Summary**
|
||||
|
||||
By using **cfssl**, you've:
|
||||
|
||||
- Created a self-signed CA certificate.
|
||||
- Generated a server certificate for your Nacos server signed by the CA.
|
||||
- Configured your Nacos server to use the new SSL certificate.
|
||||
- Imported the CA certificate into your Spring Boot application's Docker container, ensuring trust.
|
||||
- Configured your application to communicate with the Nacos server over HTTPS.
|
||||
|
||||
This setup enhances security by establishing a trusted SSL connection between your application and the Nacos server.
|
||||
|
||||
---
|
||||
|
||||
## **Next Steps**
|
||||
|
||||
- **Automate Certificate Management**: Consider automating certificate renewal and distribution.
|
||||
- **Use a Trusted CA in Production**: For production environments, obtain certificates from a trusted Certificate Authority.
|
||||
- **Monitor SSL Connections**: Implement monitoring to detect and resolve SSL issues promptly.
|
||||
|
||||
---
|
||||
|
||||
## **References**
|
||||
|
||||
- [cfssl GitHub Repository](https://github.com/cloudflare/cfssl)
|
||||
- [Nacos Documentation](https://nacos.io/en-us/docs/what-is-nacos.html)
|
||||
- [Spring Boot SSL Configuration](https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#howto-configure-ssl)
|
||||
|
||||
---
|
||||
|
||||
Feel free to ask if you have any questions or need further assistance with any of the steps!
|
||||
@@ -0,0 +1,3 @@
|
||||
|
||||
|
||||
db.createUser({ user: "unifi", pwd: "unifi", roles: [{ role: "readWrite", db: "unifi" }] })
|
||||
+34
@@ -0,0 +1,34 @@
|
||||
Title: "[Better Developers] Computers Are Cheap. People Are Expensive."
|
||||
Author:
|
||||
From:
|
||||
|
||||
## Highlights:
|
||||
|
||||
My point is that it took a long time for people to realize that it was OK to work with a high-level language, and that doing so didn't make you a worse programmer. When you use a high-level language, your programs might run a bit more slowly, but that's often an acceptable compromise.
|
||||
|
||||
---
|
||||
|
||||
**==In today's world, computers are cheap, while people are expensive.==**
|
||||
|
||||
---
|
||||
|
||||
Let's assume that a Python program runs twice as slowly as the equivalent Java program, and thus requires two servers instead of one server. In today's world, that server difference will probably cost a few hundred dollars per month. If the programmer writing the software is 5x as productive, then that server is more than paid for by the increase in efficiency.
|
||||
|
||||
---
|
||||
|
||||
This doesn't mean, of course, that you don't need to worry about slow code, or that there's no need for C++ programmers in the world any more. But the need for speed is increasingly balanced by something even more important: The need for maintainable software.
|
||||
|
||||
---
|
||||
|
||||
One of the reasons I love Python is that the code is clear and readable, allowing me to join a new project and dive in, because the code is written similarly to all of the other Python code I've read and written over the years.
|
||||
|
||||
---
|
||||
|
||||
Better to save your colleagues (and company) money by making things more efficient for people, rather than for computers.
|
||||
|
||||
---
|
||||
|
||||
Your 1st comment on this article **Note:** Really interesting insight with the switch to a high level language to save people time and make debugging easier instead of saving server resources. It might not always be the right equation like in our case where the biggest expense are the servers but in many cases it would be true that human price > server price
|
||||
|
||||
---
|
||||
|
||||
@@ -0,0 +1,7 @@
|
||||
https://nvd.nist.gov/developers/confirm-api-key?uuid=40BC52EA-8655-F011-835C-129478FCB64D
|
||||
|
||||
|
||||
API Key:
|
||||
```
|
||||
5933b86c-fe7c-4836-8959-345214c5a003
|
||||
```
|
||||
@@ -0,0 +1,11 @@
|
||||
|
||||
|
||||
```bash
|
||||
$ cosign generate-key-pair
|
||||
Enter password for private key:
|
||||
Enter password for private key again:
|
||||
Private key written to cosign.key
|
||||
Public key written to cosign.pub
|
||||
|
||||
```
|
||||
password: windyboy
|
||||
@@ -0,0 +1,38 @@
|
||||
|
||||
Hi Amin,
|
||||
|
||||
Thanks for posting in the community. We are happy to help you.
|
||||
|
||||
According to your description, the situation on your end is likely caused by your organization's settings/policies (e.g. conditional access policy).
|
||||
|
||||
You can try the following steps, and then check if it still happens or not.
|
||||
|
||||
1. Please sign out your accounts from Office applications, then close all Office applications.
|
||||
|
||||
2. Open File Explorer, paste the following path, and delete all files and folders.
|
||||
|
||||
%localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
|
||||
|
||||
3. In the Windows search bar, search for "Access Work or School".
|
||||
|
||||
4. Check if you can see your business account in "Access Work or School".
|
||||
|
||||
- If you don't see it, please select Connect and add your business account.
|
||||
|
||||
|
||||
- If you can see it, please select it and select Disconnect. After that, please click "Connect" and log into your account again to register the device.
|
||||
|
||||
|
||||
5. Run one Office application, such as Word, sign into your account, and check again.
|
||||
|
||||
If the error message still appears after trying the above steps, I recommend you report the situation to your organization admin or IT department.
|
||||
|
||||
We look forward to your response. Thanks for your cooperation.
|
||||
|
||||
Sincerely,
|
||||
|
||||
George | Microsoft Community Moderator
|
||||
|
||||
[Updated by George Jiang MSFT 04:33 AM 08/10 2024 UTC + 8]
|
||||
|
||||
• Beware of Scammers posting fake Support Numbers here.
|
||||
@@ -0,0 +1,5 @@
|
||||
亲，以下是您购买的商品信息。
|
||||
MobaXterm Professional 便携版
|
||||
下载地址https://wwxs.lanzoum.com/ieYNw0s21tab
|
||||
备用地址https://www.987123.xyz/oss/lovemei9/MobaXterm/MobaXterm_Portable_v23.1.zip
|
||||
说明：复制以上地址进行下载，软件包中已经集成授权文件，下载后解压即用。
|
||||
@@ -0,0 +1,3 @@
|
||||
|
||||
api:
|
||||
secret_WggiGblW3PayQXirTeOCrS9FTsQ5EWGWHjInmNcvJdv
|
||||
@@ -0,0 +1,86 @@
|
||||
|
||||
Here is the **definitive, consolidated guide** for setting up Playwright on **Arch Linux (WSL)**.
|
||||
|
||||
This summary skips the trial-and-error we just went through and provides the "Happy Path" to get everything working in one go.
|
||||
|
||||
---
|
||||
|
||||
### 📋 Prerequisites
|
||||
* **WSL 2** (Recommended).
|
||||
* **Proxy (Optional):** If you are behind a proxy, remember to use `sudo -E` to preserve environment variables.
|
||||
|
||||
---
|
||||
|
||||
### 🚀 Step 1: System Prep & Node.js
|
||||
First, ensure your package database is fresh (fixes 404 errors) and install Node.js.
|
||||
|
||||
```bash
|
||||
# Update system and install Node.js/npm
|
||||
# Use -E if you have https_proxy set in your shell
|
||||
sudo -E pacman -Syu nodejs npm
|
||||
```
|
||||
|
||||
### 📦 Step 2: Install System Dependencies (The Critical Step)
|
||||
**Do not** use `npx playwright install-deps` (it fails on Arch). Instead, install these packages manually. This list includes all the X11, Graphics, and Network libraries required by Chromium, Firefox, and WebKit.
|
||||
|
||||
```bash
|
||||
sudo -E pacman -S --needed \
|
||||
git \
|
||||
nss \
|
||||
nspr \
|
||||
libdrm \
|
||||
alsa-lib \
|
||||
mesa \
|
||||
gtk3 \
|
||||
at-spi2-core \
|
||||
pango \
|
||||
cairo \
|
||||
gdk-pixbuf2 \
|
||||
libx11 \
|
||||
libxcomposite \
|
||||
libxdamage \
|
||||
libxext \
|
||||
libxfixes \
|
||||
libxrandr \
|
||||
libxcursor \
|
||||
libxi \
|
||||
libxrender \
|
||||
libxcb \
|
||||
freetype2 \
|
||||
fontconfig \
|
||||
ffmpeg
|
||||
```
|
||||
|
||||
### 🛠️ Step 3: Initialize Playwright
|
||||
Set up your project and download the browser binaries (these are separate from the system libs above).
|
||||
|
||||
```bash
|
||||
# Create project directory
|
||||
mkdir my-tests && cd my-tests
|
||||
|
||||
# Initialize (Select TypeScript/JavaScript as preferred)
|
||||
npm init playwright@latest
|
||||
|
||||
# If prompted to "Install Playwright browsers", select True.
|
||||
# If you need to install them manually later:
|
||||
npx playwright install
|
||||
```
|
||||
|
||||
### ✅ Step 4: Run Tests
|
||||
You are now ready to run.
|
||||
|
||||
```bash
|
||||
npx playwright test
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 💡 Troubleshooting Cheat Sheet
|
||||
|
||||
| Issue | Solution |
|
||||
| :------------------------ | :-------------------------------------------------------------------------------- |
|
||||
| **`install-deps` fails** | **Ignore it.** It only supports Ubuntu. Use the `pacman` command in Step 2. |
|
||||
| **`libxxx.so not found`** | You are missing a package. Use `pkgfile libxxx.so` to find the Arch package name. |
|
||||
| **404 Errors (Pacman)** | Your mirrors are out of sync. Run `sudo pacman -Syu` to refresh. |
|
||||
| **Browser won't launch** | Ensure `nspr` and `nss` are installed (included in Step 2). |
|
||||
| **GUI/Headless issues** | If visual mode fails, try `xvfb-run npx playwright test`. |
|
||||
@@ -0,0 +1,173 @@
|
||||
|
||||
To set up **Oh My Posh** with **Zsh** on **Debian 12**, follow these steps to install the necessary components and configure your terminal prompt.
|
||||
|
||||
## Installation Steps
|
||||
|
||||
### 1. Download the Oh My Posh Binary
|
||||
First, you need to download the Oh My Posh binary suitable for Linux. Open your terminal and run the following command:
|
||||
|
||||
```bash
|
||||
sudo wget https://github.com/JanDeDobbeleer/oh-my-posh/releases/latest/download/posh-linux-amd64 -O /usr/local/bin/oh-my-posh
|
||||
```
|
||||
|
||||
### 2. Set Executable Permissions
|
||||
Make the downloaded binary executable:
|
||||
|
||||
```bash
|
||||
sudo chmod +x /usr/local/bin/oh-my-posh
|
||||
```
|
||||
|
||||
### 3. Create a Directory for Themes
|
||||
You need a directory to store your themes. Create it using:
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.poshthemes
|
||||
```
|
||||
|
||||
### 4. Download Themes
|
||||
You can download predefined themes from the Oh My Posh repository. For example, to download the latest themes, run:
|
||||
|
||||
```bash
|
||||
wget https://github.com/JanDeDobbeleer/oh-my-posh/releases/latest/download/themes.zip -O ~/.poshthemes/themes.zip
|
||||
```
|
||||
|
||||
Unzip the downloaded file:
|
||||
|
||||
```bash
|
||||
unzip ~/.poshthemes/themes.zip -d ~/.poshthemes
|
||||
```
|
||||
|
||||
Then, clean up by removing the zip file:
|
||||
|
||||
```bash
|
||||
rm ~/.poshthemes/themes.zip
|
||||
```
|
||||
|
||||
### 5. Update Your Zsh Configuration
|
||||
Now, you need to configure your Zsh shell to use Oh My Posh. Open your `.zshrc` file in a text editor:
|
||||
|
||||
```bash
|
||||
nano ~/.zshrc
|
||||
```
|
||||
|
||||
Add the following line at the end of the file to initialize Oh My Posh with a specific theme (replace `alien` with your preferred theme name):
|
||||
|
||||
```bash
|
||||
eval "$(oh-my-posh --init --shell zsh --config ~/.poshthemes/alien.omp.json)"
|
||||
```
|
||||
|
||||
### 6. Apply Changes
|
||||
After saving and closing the `.zshrc` file, apply the changes by running:
|
||||
|
||||
```bash
|
||||
source ~/.zshrc
|
||||
```
|
||||
|
||||
## Additional Configuration
|
||||
|
||||
### Install a Nerd Font (Optional)
|
||||
For better aesthetics, install a Nerd Font that supports icons used by Oh My Posh. You can download fonts like **Meslo** or **Fira Code** from their respective repositories and install them on your system.
|
||||
|
||||
### Set Terminal Font
|
||||
Finally, ensure that your terminal emulator is configured to use the newly installed Nerd Font for optimal display of icons and symbols.
|
||||
|
||||
By following these steps, you will have successfully set up Oh My Posh with Zsh on Debian 12, enhancing your terminal's appearance and functionality.
|
||||
|
||||
Citations:
|
||||
[1] https://dev.to/karleeov/wsl-arch-setup-for-oh-my-posh-51pa
|
||||
[2] https://www.reddit.com/r/NixOS/comments/1ge1gwn/how_to_set_ohmyposh_settings/
|
||||
[3] https://ohmyposh.dev/docs/installation/linux
|
||||
[4] https://www.librebyte.net/en/cli-en/oh-my-posh-a-beatifull-prompt-for-your-shell/
|
||||
[5] https://www.youtube.com/watch?v=nGHgyPLi7UM
|
||||
[6] https://calebschoepp.com/blog/2021/how-to-setup-oh-my-posh-on-ubuntu/
|
||||
[7] https://www.linux.org/threads/need-help-finalizing-oh-my-posh-bash-terminal.52617/
|
||||
|
||||
|
||||
|
||||
.zshrc
|
||||
```
|
||||
#go lang
|
||||
export GOROOT=/usr/local/go
|
||||
export GOPATH=/home/windy/go-lang
|
||||
export PATH=$PATH:$GOROOT/bin:$GOPATH/bin
|
||||
|
||||
eval "$(oh-my-posh --init --shell zsh --config ~/.poshthemes/powerlevel10k_modern.omp.json)"
|
||||
|
||||
|
||||
[ -f ~/.fzf.zsh ] && source ~/.fzf.zsh
|
||||
|
||||
|
||||
# Zinit setup and plugin management
|
||||
ZINIT_HOME="${XDG_DATA_HOME:-${HOME}/.local/share}/zinit/zinit.git"
|
||||
[ ! -d $ZINIT_HOME ] && mkdir -p "$(dirname $ZINIT_HOME)"
|
||||
[ ! -d $ZINIT_HOME/.git ] && git clone https://github.com/zdharma-continuum/zinit.git "$ZINIT_HOME"
|
||||
source "${ZINIT_HOME}/zinit.zsh"
|
||||
|
||||
# Load essential annexes (non-turbo mode for annex functionality)
|
||||
zinit light-mode for \
|
||||
zdharma-continuum/zinit-annex-as-monitor \
|
||||
zdharma-continuum/zinit-annex-bin-gem-node \
|
||||
zdharma-continuum/zinit-annex-patch-dl \
|
||||
zdharma-continuum/zinit-annex-rust
|
||||
|
||||
# Load Zeno plugin with keybindings
|
||||
zinit ice lucid depth"1" blockf
|
||||
zinit light yuki-yano/zeno.zsh
|
||||
|
||||
if [[ -n $ZENO_LOADED ]]; then
|
||||
bindkey ' ' zeno-auto-snippet
|
||||
bindkey '^m' accept-line
|
||||
bindkey '^i' zeno-completion
|
||||
bindkey '^g' zeno-ghq-cd
|
||||
bindkey '^r' zeno-history-selection
|
||||
bindkey '^x' zeno-insert-snippet
|
||||
fi
|
||||
|
||||
# Load additional Zsh plugins
|
||||
zinit ice wait"0"; zinit light zsh-users/zsh-completions
|
||||
autoload -Uz compinit && compinit
|
||||
zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'
|
||||
zstyle ':completion:*:default' menu select=1
|
||||
|
||||
zinit light zsh-users/zsh-syntax-highlighting
|
||||
zinit light zsh-users/zsh-autosuggestions
|
||||
zinit light Aloxaf/fzf-tab
|
||||
|
||||
# FZF configuration
|
||||
zi ice from"gh-r" as"program"
|
||||
zi light junegunn/fzf
|
||||
|
||||
# Auto-suggestions styling
|
||||
ZSH_AUTOSUGGEST_HIGHLIGHT_STYLE="fg=244"
|
||||
|
||||
# History settings
|
||||
HISTFILE=~/.zsh-history
|
||||
HISTSIZE=100000
|
||||
SAVEHIST=1000000
|
||||
HISTDUP=erase
|
||||
setopt appendhistory sharehistory hist_ignore_space hist_ignore_all_dups
|
||||
setopt hist_save_no_dups hist_ignore_dups hist_find_no_dups
|
||||
setopt inc_append_history share_history
|
||||
|
||||
# Zsh options for usability
|
||||
setopt AUTO_CD
|
||||
setopt AUTO_PARAM_KEYS
|
||||
|
||||
# Completion and FZF styling
|
||||
zstyle ':completion:*' matcher-list 'm:{a-z}={A-Za-z}'
|
||||
zstyle ':completion:*' list-colors "${(s.:.)LS_COLORS}"
|
||||
zstyle ':completion:*' menu no
|
||||
zstyle ':fzf-tab:complete:cd:*' fzf-preview 'ls --color $realpath'
|
||||
|
||||
# Load additional plugins with default keys
|
||||
zinit pack"default+keys" for fzf
|
||||
|
||||
# Ensure Zinit autocompletion
|
||||
autoload -Uz _zinit
|
||||
(( ${+_comps} )) && _comps[zinit]=_zinit
|
||||
|
||||
# Consolidate PATH with deduplication
|
||||
export PATH=$(echo "/run/current-system/sw/bin:/usr/local/bin:/usr/local/sbin:$PATH" | tr ':' '\n' | awk '!seen[$0]++' | tr '\n' ':' | sed 's/:$//')
|
||||
|
||||
|
||||
```
|
||||
@@ -0,0 +1,7 @@
|
||||
|
||||
experimental:
|
||||
interface-name: eth0 //上网的网卡
|
||||
|
||||
创建tap设备
|
||||
打开tap设备属性，更改 share
|
||||
共享的网卡选择热点的网卡 wlan1
|
||||
@@ -0,0 +1,42 @@
|
||||
|
||||
|
||||
<h2>Common Options</h2>
|
||||
<div>-#, --progress-bar Make curl display a simple progress bar instead of the more informational standard meter.</div>
|
||||
<div>-b, --cookie <name=data> Supply cookie with request. If no =, then specifies the cookie file to use (see -c).</div>
|
||||
<div>-c, --cookie-jar <file name> File to save response cookies to.</div>
|
||||
<div>-d, --data <data> Send specified data in POST request. Details provided below.</div>
|
||||
<div>-f, --fail Fail silently (don't output HTML error form if returned).</div>
|
||||
<div>-F, --form <name=content> Submit form data.</div>
|
||||
<div>-H, --header <header> Headers to supply with request.</div>
|
||||
<div>-i, --include Include HTTP headers in the output.</div>
|
||||
<div>-I, --head Fetch headers only.</div>
|
||||
<div>-k, --insecure Allow insecure connections to succeed.</div>
|
||||
<div>-L, --location Follow redirects.</div>
|
||||
<div>-o, --output <file> Write output to . Can use --create-dirs in conjunction with this to create any directories specified in the -o path.</div>
|
||||
<div>-O, --remote-name Write output to file named like the remote file (only writes to current directory).</div>
|
||||
<div>-s, --silent Silent (quiet) mode. Use with -S to force it to show errors.</div>
|
||||
<div>-v, --verbose Provide more information (useful for debugging).</div>
|
||||
<div>-w, --write-out <format> Make curl display information on stdout after a completed transfer. See man page for more details on available variables. Convenient way to force curl to append a newline to output: -w "\n" (can add to ~/.curlrc).</div>
|
||||
<div>-X, --request The request method to use.</div>
|
||||
<h2>POST</h2>
|
||||
<div>When sending data via a POST or PUT request, two common formats (specified via the Content-Type header) are:</div>
|
||||
<ul><li><div>application/json</div></li><li><div>application/x-www-form-urlencoded</div></li></ul>
|
||||
<div>Many APIs will accept both formats, so if you're using curl at the command line, it can be a bit easier to use the form urlencoded format instead of json because</div>
|
||||
<ul><li><div>the json format requires a bunch of extra quoting</div></li><li><div>curl will send form urlencoded by default, so for json the Content-Type header must be explicitly set</div></li></ul>
|
||||
<div>This gist provides examples for using both formats, including how to use sample data files in either format with your curl requests.</div>
|
||||
<h2>curl usage</h2>
|
||||
<div>For sending data with POST and PUT requests, these are common curl options:</div>
|
||||
<ul><li><div>request type</div></li><ul><li><div>-X POST</div></li><li><div>-X PUT</div></li></ul><li><div>content type header</div></li><li><div>-H "Content-Type: application/x-www-form-urlencoded"</div></li><li><div>-H "Content-Type: application/json"</div></li><li><div>data</div></li><ul><li><div>form urlencoded: -d "param1=value1&m2=value2" or -d @data.txt</div></li><li><div>json: -d '{"key1":"value1", "key2":"value2"}' or -d @data.json</div></li></ul></ul>
|
||||
<h2>Examples</h2>
|
||||
<h3>POST application/x-www-form-urlencoded</h3>
|
||||
<div>application/x-www-form-urlencoded is the default:</div>
|
||||
<div>curl -d "param1=value1&m2=value2" -X POST http://localhost:3000/data</div>
|
||||
<div>explicit:</div>
|
||||
<div>curl -d "param1=value1&m2=value2" -H "Content-Type: application/x-www-form-urlencoded" -X POST http://localhost:3000/data</div>
|
||||
<div>with a data file</div>
|
||||
<div>curl -d "@data.txt" -X POST http://localhost:3000/data</div>
|
||||
<h3>POST application/json</h3>
|
||||
<div>curl -d '{"key1":"value1", "key2":"value2"}' -H "Content-Type: application/json" -X POST http://localhost:3000/data</div>
|
||||
<div>with a data file</div>
|
||||
<div>curl -d "@data.json" -X POST http://localhost:3000/data</div>
|
||||
<div><br></div>
|
||||
@@ -0,0 +1,15 @@
|
||||
Java parameters references:
|
||||
[Gradle Java Plugin](https://docs.gradle.org/current/userguide/java_plugin.html)
|
||||
|
||||
Running only certain test to debug problems:
|
||||
```
|
||||
gradle test --tests org.gradle.SomeTest.someSpecificFeature
|
||||
gradle test --tests *SomeTest.someSpecificFeature
|
||||
gradle test --tests *SomeSpecificTest
|
||||
gradle test --tests all.in.specific.package*
|
||||
gradle test --tests *IntegTest
|
||||
gradle test --tests *IntegTest*ui*
|
||||
gradle test --tests *IntegTest.singleMethod
|
||||
gradle someTestTask --tests *UiTest someOtherTestTask --tests *WebTest*ui
|
||||
```
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
### Notes
|
||||
```dataview
|
||||
table file.ctime as Date from "300-resources/Drawing"
|
||||
sort file.name
|
||||
```
|
||||
@@ -0,0 +1,10 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,9 @@
|
||||
|
||||
文明7标准：
|
||||
```
|
||||
7I0EZ-N5HWF-JYIGF
|
||||
```
|
||||
激活码2：
|
||||
```
|
||||
EIFGE-K032P-RQ8BH
|
||||
```
|
||||
@@ -0,0 +1,5 @@
|
||||
### Notes
|
||||
```dataview
|
||||
table file.ctime as Date from "300-resources/Gaming"
|
||||
sort file.name
|
||||
```
|
||||
@@ -0,0 +1,6 @@
|
||||
- Dwarf fortress
|
||||
- Lutris
|
||||
- Crusader Kings
|
||||
- Katana Zero
|
||||
- Factorio
|
||||
- [Space Station 13](https://spacestation13.com/)
|
||||
@@ -0,0 +1,18 @@
|
||||
|
||||
|
||||
床边衣柜
|
||||
|
||||
高 38
|
||||
宽 35
|
||||
深 39
|
||||
|
||||
床角衣柜
|
||||
上柜下层：
|
||||
|
||||
宽：69
|
||||
深：56
|
||||
高：27.5
|
||||
隔板深：39.5
|
||||
|
||||
|
||||
|
||||
@@ -0,0 +1,5 @@
|
||||
|
||||
厨房清洁剂储物盒子
|
||||
```
|
||||
24*24*40
|
||||
```
|
||||
@@ -0,0 +1,73 @@
|
||||
https://productled.com/product-qualified-leads/
|
||||
|
||||
A product qualified lead (PQL) is a lead who has experienced meaningful value using your product through a free trial or freemium model.
|
||||
|
||||
When you reach out to a PQL, they should have already experienced meaningful value in your product. This makes the sale easier because there's no need to sell the user on the value of the product.
|
||||
|
||||
Before we dive into how to identify a PQL, I wanted to take a second to list out what PQLs are NOT: PQLs are not people who upgrade their free plan; PQLs are not marketing qualified leads; Someone who signs up for a free trial does NOT qualify as a PQL;
|
||||
|
||||
To choose a successful PQL definition, it has to involve helping the user become successful in your product. I\'ll share a few great examples with you in a second.
|
||||
|
||||
What matters, however, is that you try to find behaviors that correlate with people upgrading.
|
||||
|
||||
To really nail down the ideal definition of a PQL, you need to know your value metrics. According to Patrick Campbell (the CEO and co-founder of Price Intelligently), the perfect value metric should align with your customers' needs, grow with them and be easy to wrap one's mind around.
|
||||
|
||||
No business should have the same product qualified lead definition.
|
||||
|
||||
Every business should be constantly refining what their PQL definition is and make sure it helps users experience meaningful value in the product. Here are just a few examples of PQL definitions from well-known brands: For Slack, a PQL is when an account reaches its 2,000 message limit; For Facebook, a PQL is once someone adds 7 friends; For Drift, a PQL is once someone has 100 conversations on their website;
|
||||
|
||||
As a result, PQLs close at significantly higher rates than MQLs because users understand the value of your product. It's not uncommon for PQLs to convert upwards of 20-30% in my experience working with B2B SaaS businesses.
|
||||
|
||||
As prospects utilize your application, they demonstrate buying intent based on product behaviors which can include: Product interest Number of users Features used Spending patterns Usage patterns Velocity - How fast a user or team is adopting your product
|
||||
|
||||
Once you have that in place, I recommend brainstorming a few PQL definitions as a start. Even if it's just a hypothesis at this point, it will come in handy when you test it in your business
|
||||
|
||||
I find that usage patterns are one of the easiest ways to define a PQL if you're short for time. At first, your PQL could be as simple as a user that logs in 10 times. This at least shows that the user is
|
||||
actively using the product and is coming back for a reason.
|
||||
|
||||
Now, the next step is to find out what they're coming back to do. Like I mentioned before, your PQL is meant to be a moving target. You can start with usage patterns but eventually, you want to get closer to pinning what the leading behaviors of someone who becomes a paying customer are
|
||||
|
||||
Once you have your PQL definition, you need to put the systems in place so that all teams can play an active role in generating more PQLs. This is not a solo sport. In this section, I break down some of the key metrics each team can be responsible for.
|
||||
|
||||
When setting up metrics for teams, I always recommend having both a quantity and a quality metric to ensure that each team isn't sacrificing quality in order to attain the quantity metric
|
||||
|
||||
important that it reflects that we're upgrading users that become and stay as successful customers.
|
||||
|
||||
One of the best parts about PQLs is that it aligns teams to focus on helping the user become successful in the product.
|
||||
|
||||
Updated Nov 16, 2019:
|
||||
|
||||
A product qualified lead (PQL) is a lead who has experienced meaningful value using your product through a free trial or freemium model.
|
||||
|
||||
When you reach out to a PQL, they should have already experienced meaningful value in your product. This makes the sale easier because there's no need to sell the user on the value of the product.
|
||||
|
||||
Before we dive into how to identify a PQL, I wanted to take a second to list out what PQLs are NOT: PQLs are not people who upgrade their free plan; PQLs are not marketing qualified leads; Someone who signs up for a free trial does NOT qualify as a PQL;
|
||||
|
||||
To choose a successful PQL definition, it has to involve helping the user become successful in your product. I\'ll share a few great examples with you in a second.
|
||||
|
||||
What matters, however, is that you try to find behaviors that correlate with people upgrading.
|
||||
|
||||
To really nail down the ideal definition of a PQL, you need to know your value metrics. According to Patrick Campbell (the CEO and co-founder of Price Intelligently), the perfect value metric should align with your customers' needs, grow with them and be easy to wrap one's mind around.
|
||||
|
||||
No business should have the same product qualified lead definition.
|
||||
|
||||
Every business should be constantly refining what their PQL definition is and make sure it helps users experience meaningful value in the product. Here are just a few examples of PQL definitions from well-known brands: For Slack, a PQL is when an account reaches its 2,000 message limit; For Facebook, a PQL is once someone adds 7 friends; For Drift, a PQL is once someone has 100 conversations on their website;
|
||||
|
||||
As a result, PQLs close at significantly higher rates than MQLs because users understand the value of your product. It's not uncommon for PQLs to convert upwards of 20-30% in my experience working with B2B SaaS businesses.
|
||||
|
||||
As prospects utilize your application, they demonstrate buying intent based on product behaviors which can include: Product interest Number of users Features used Spending patterns Usage patterns Velocity - How fast a user or team is adopting your product
|
||||
|
||||
Once you have that in place, I recommend brainstorming a few PQL definitions as a start. Even if it's just a hypothesis at this point, it will come in handy when you test it in your business
|
||||
|
||||
I find that usage patterns are one of the easiest ways to define a PQL if you're short for time. At first, your PQL could be as simple as a user that logs in 10 times. This at least shows that the user is
|
||||
actively using the product and is coming back for a reason.
|
||||
|
||||
Now, the next step is to find out what they're coming back to do. Like Imentioned before, your PQL is meant to be a moving target. You can start with usage patterns but eventually, you want to get closer to pinning what the leading behaviors of someone who becomes a paying customer are
|
||||
|
||||
Once you have your PQL definition, you need to put the systems in place so that all teams can play an active role in generating more PQLs. This is not a solo sport. In this section, I break down some of the key metrics each team can be responsible for.
|
||||
|
||||
When setting up metrics for teams, I always recommend having both a quantity and a quality metric to ensure that each team isn't sacrificing quality in order to attain the quantity metric
|
||||
|
||||
important that it reflects that we're upgrading users that become and stay as successful customers.
|
||||
|
||||
One of the best parts about PQLs is that it aligns teams to focus on helping the user become successful in the product.
|
||||
@@ -0,0 +1,9 @@
|
||||
Tags: [[Email]] [[Marketing]] - [[Audience]] [[Customer]] [[Local]]
|
||||
Author: [[Seth Godin]]
|
||||
## Highlights:
|
||||
|
||||
With few exceptions, that’s being replaced by a return to clusters.
|
||||
|
||||
The cluster might be geographic (they eat different potato chips in Tucscon than they do in Milwaukee) but they’re much more likely to be psychographic instead. What a group of people believe, who they connect with, what they hope for…
|
||||
|
||||
The minimal viable audience concept requires that you find your cluster and overwhelm them with delight. Choose the right cluster, show up with the right permission and sufficient magic and generosity and the idea will spread.
|
||||
+29
@@ -0,0 +1,29 @@
|
||||
https://www.forbes.com/sites/forbesbusinesscouncil/2019/11/21/consumers-are-hungry-for-an-experience-based-connection-with-your-brand/
|
||||
|
||||
According to one study, 83% of consumers admit paying as much attention to how brands treat them as on the product they sell. The same study states that 73% say they are willing to pay more for a product if they love the brand. These statistics call attention to the fact that customer experience is critical.
|
||||
|
||||
re-imagine every touchpoint a consumer has with their brand, delivering an experience-based, emotional connection. These organizations are looking past traditional ways to attract and retain customers and designing compelling, personalized experiences – via advanced technologies – around products and services to better engage.
|
||||
|
||||
The term “Experience Economy” was coined a few decades ago by James H. Gilmore and B. Joseph Pine II. The two, who co-authored a book of the same name, describe that consumers seek experiences above and beyond products and services. In the book, they explain that services must be mass-customized for each individual need and that offerings must be charged for time (i.e., subscriptions). They also urge more organizations to pay attention not just to what workers should do, but how they do it.
|
||||
|
||||
The customer experience is not merely about your mobile app, your website or your call center agents – it runs deep inside the four walls of your company. All of the internal processes, people and systems that contribute to your brand’s overall customer experience – those operations that take place behind the scenes – are just as much a part of that customer experience.
|
||||
|
||||
First and foremost, brand interactions must be easy for consumers. They must co-exist in the natural rhythm of consumers’ daily lives.
|
||||
|
||||
From a consumer’s perspective, what matters most is that their brand interaction simply works and provides value
|
||||
|
||||
Part of this strategy involves leveraging technology and data to decode the nuances of consumer behaviors and sensibilities that drive their unique brand interactions and decision-making processes
|
||||
|
||||
Don’t generalize your customers and prospects.
|
||||
|
||||
These lenses are too narrowly focused and don’t expose the more valuable behavioral criteria that inspire long-term, emotional connections. Intead, utilize technology to develop a more robust, data-driven picture of your audience.
|
||||
|
||||
consumers ourselves, perhaps many of us are used to accessing anything we want, at any given time, through all of our connected networks. Similarly, customers expect their brand experiences to be on the ready, whether it’s via a smartphone, tablet or any other device
|
||||
|
||||
no longer to dictate an exchange but to facilitate one.
|
||||
|
||||
Develop a strategy that accounts for business needs, market demands and technology
|
||||
|
||||
the Experience Economy must be backed by your data
|
||||
|
||||
Utilize your back-office to generate the right amount of data about individual consumers.
|
||||
@@ -0,0 +1,5 @@
|
||||
### Notes
|
||||
```dataview
|
||||
table file.ctime as Date from "300-resources/Marketing"
|
||||
sort file.name
|
||||
```
|
||||
@@ -0,0 +1,19 @@
|
||||
Tags: [[Article]] [[Marketing]] - [[Entrepreneurship]] [[Validation]]
|
||||
Author: [[Alex Hillman]]
|
||||
From: https://stackingthebricks.com/validation-is-backwards/
|
||||
|
||||
## Highlights:
|
||||
|
||||
On one hand, it’s possible that Lean methods could protect you from making a huge mistake, by making many smaller mistakes instead. You could avoid wasting a whole lot of time and money on a shitty, half-cocked business idea. And hey, that’s not all bad!
|
||||
|
||||
Validation claims to be a data-driven process, but the results are neither predictably nor repeatably successful.
|
||||
|
||||
“Before you launch, you’ll interview people who may be potential customers, but have not yet given you money, and are ergo not customers. They’ve got no skin in the game, no frame of reference to build on. But even after you launch - and you begin to interview your customers - the technique is flawed.
|
||||
|
||||
You rely on your interviewees being experts at research & development — you trust them to identify their own pains with unflinching honesty and accuracy. To remember, in essence, exactly what they do, all day, every day. And to be willing to tell you about it. And to be able to imagine a world unlike the world they inhabit, with a different workflow, different tools, different outlook, different life. You rely on them to accurately identify the causes of the pains they do identify. You rely on them to be wholly rational. They must not care about your feelings at all
|
||||
|
||||
You need them to be people who always do exactly what they say they will.”
|
||||
|
||||
The process that we created and teach in 30x500 is based on an observational research technique called Ethnography
|
||||
|
||||
answers you need for repeatable business success: understanding peoples’ behaviors, specifically why they do (or don’t do) things, and why they buy (or don’t buy) things.
|
||||
@@ -0,0 +1,43 @@
|
||||
|
||||
|
||||
# ipv6
|
||||
|
||||
## dhcpv6
|
||||
|
||||
* lan:
|
||||
内置ipv6管理
|
||||
强制链路
|
||||
1 个 /60 子网：
|
||||
240e:3c1:5665:1cd0::/60
|
||||
dhcp:
|
||||
ignore
|
||||
ipv6:
|
||||
server
|
||||
server
|
||||
relay
|
||||
无状态+有状态
|
||||
总是通告默认路由
|
||||
* wan
|
||||
默认网关
|
||||
内置ipv6管理
|
||||
* wan6
|
||||
协议：dhcpv6 客户端
|
||||
请求： try
|
||||
指定前缀长度： 自动
|
||||
内置ipv6管理
|
||||
|
||||
软件包：
|
||||
odhcp6c
|
||||
odhcpd-ipv6only
|
||||
luci-proto-ipv6
|
||||
|
||||
wireguard
|
||||
```shell
|
||||
# wg genkey | tee privatekey | wg pubkey > publickey
|
||||
# cat privatekey
|
||||
SD8TBcD75GATvEAebOkb4MVf+VeECUKuo9bzZscBHFg=
|
||||
# cat publickey
|
||||
8mszNqg5s4YFA2z3Q/5A9HYXEnQIbNNReW0QxSlELng=
|
||||
```
|
||||
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
List:
|
||||
- New application features and menu
|
||||
- Focus mode for the current line
|
||||
- Focus UI for writing
|
||||
@@ -0,0 +1,365 @@
|
||||
/* Special Font */
|
||||
body, p {
|
||||
font-family: "Dank Mono",'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Microsoft YaHei Light", sans-serif;
|
||||
}
|
||||
|
||||
.cm-s-obsidian {
|
||||
font-family: "Dank Mono",'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Microsoft YaHei Light", sans-serif;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
.editor {
|
||||
font-family: "Dank Mono",'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Microsoft YaHei Light", sans-serif;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
.markdown-preview-view code {
|
||||
font-family: "Dank Mono",'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Microsoft YaHei Light", sans-serif;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
.preview {
|
||||
font-family: "Dank Mono",'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Microsoft YaHei Light", sans-serif;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
/* Scrollbar */
|
||||
::-webkit-scrollbar {
|
||||
background-color: transparent;
|
||||
}
|
||||
|
||||
/**/
|
||||
/* Editor Section */
|
||||
/**/
|
||||
/* Line size */
|
||||
.cm-s-obsidian pre.HyperMD-header {
|
||||
line-height: 1!important;
|
||||
}
|
||||
|
||||
/* Selection */
|
||||
.theme-light {
|
||||
--text-selection: rgba(112, 93, 207, 0.5);
|
||||
}
|
||||
|
||||
.theme-dark {
|
||||
--text-selection: rgba(112, 93, 207, 0.5);
|
||||
}
|
||||
|
||||
::selection {
|
||||
background-color: #705dcf;
|
||||
color: white;
|
||||
}
|
||||
|
||||
/* Title */
|
||||
/* Current main pane */
|
||||
.view-header-title {
|
||||
color: #705dcf;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.workspace-leaf.mod-active .view-header {
|
||||
text-align: center;
|
||||
}
|
||||
/* Other pane */
|
||||
.workspace-leaf-header-title-container {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
/* Headers */
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-1.cm-header.cm-header-1 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-2.cm-header.cm-header-2 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-3.cm-header.cm-header-3 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-4.cm-header.cm-header-4 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-5.cm-header.cm-header-5 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-6.cm-header.cm-header-6 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
/* Header folder icon */
|
||||
.CodeMirror-foldgutter-open, .CodeMirror-foldgutter-folded {
|
||||
color: #3e3471;
|
||||
}
|
||||
|
||||
.CodeMirror-foldgutter-open, .CodeMirror-foldgutter-folded {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
/* Cursor */
|
||||
.cm-fat-cursor .CodeMirror-cursor {
|
||||
background: #3e3471;
|
||||
}
|
||||
|
||||
.cm-animate-fat-cursor {
|
||||
background-color: #3e3471;
|
||||
}
|
||||
|
||||
/* Selection in popup ([[]] autocomplete)*/
|
||||
.suggestion-item.is-selected {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-light .suggestion-shortcut {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
/* Inner and Outer links */
|
||||
.cm-url {
|
||||
color: lightblue!important;
|
||||
}
|
||||
|
||||
.markdown-highlighting .internal-link .cl-underlined-text {
|
||||
color: var(--text-accent)!important;
|
||||
}
|
||||
|
||||
.markdown-highlighting .link .cl-underlined-text {
|
||||
color: lightblue!important;
|
||||
}
|
||||
|
||||
/* Blockquote */
|
||||
.preview blockquote {
|
||||
background-color: var(--background-modifier-border);
|
||||
border: 1px solid var(--text-muted);
|
||||
}
|
||||
|
||||
/* Highlights and Bold */
|
||||
strong {
|
||||
font-size: larger;
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
mark {
|
||||
background-color: darkgoldenrod;
|
||||
}
|
||||
|
||||
.markdown-highlighting .tag {
|
||||
color: var(--text-accent)!important;
|
||||
}
|
||||
|
||||
/* Tables */
|
||||
.markdown-preview-view th {
|
||||
background-color: #3e3471;
|
||||
color: white
|
||||
}
|
||||
|
||||
.cm-s-obsidian pre.HyperMD-table-row span.cm-hmd-table-sep {
|
||||
color: unset;
|
||||
}
|
||||
|
||||
.cm-s-obsidian pre.HyperMD-table-row-1 > span {
|
||||
color: unset;
|
||||
}
|
||||
|
||||
/* Status bar */
|
||||
.theme-dark .status-bar-item {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-light .status-bar-item {
|
||||
color: black;
|
||||
}
|
||||
|
||||
/**/
|
||||
/* Preview section */
|
||||
/**/
|
||||
/* Centered preview */
|
||||
.markdown-preview-view
|
||||
{
|
||||
padding-left: 10% !important;
|
||||
padding-right: 10% !important;
|
||||
}
|
||||
|
||||
.markdown-embed-title {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
.markdown-preview-view .markdown-embed {
|
||||
background-color: var(--background-primary-alt);
|
||||
margin-top: 0.5rem;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
|
||||
.markdown-preview-view .internal-link {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
.markdown-preview-view a {
|
||||
color: lightblue;
|
||||
}
|
||||
|
||||
/**/
|
||||
/* Side panel section */
|
||||
/**/
|
||||
/* Plugin Title and Description */
|
||||
.plugin-name {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
.plugin-description {
|
||||
color: var(--text-normal)
|
||||
}
|
||||
|
||||
/* Files title and Buttons */
|
||||
.nav-file-title-content, .nav-folder-title-content {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
.nav-action-button {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
/* File explorer navigation selection */
|
||||
.nav-file.is-active > .nav-file-title, .nav-file.is-active > .nav-folder-title, .nav-file.is-active > .nav-folder-collapse-indicator, .nav-folder.is-active > .nav-file-title, .nav-folder.is-active > .nav-folder-title, .nav-folder.is-active > .nav-folder-collapse-indicator {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
body:not(.is-grabbing) .nav-file-title:hover, body:not(.is-grabbing) .nav-folder-title:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.nav-file-title-content, .nav-folder-title-content {
|
||||
color:unset;
|
||||
}
|
||||
|
||||
.nav-folder.mod-root > .nav-file-title:hover, .nav-folder.mod-root > .nav-folder-title:hover {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
body:not(.is-grabbing) .nav-file-title:hover .nav-folder-collapse-indicator, body:not(.is-grabbing) .nav-folder-title:hover .nav-folder-collapse-indicator {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.nav-file-title, .nav-folder-title, .nav-folder-collapse-indicator {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
/* File explorer menu*/
|
||||
.menu-item:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
/* Backlinks Color and Text */
|
||||
.search-result-file-matched-text {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.search-result-file-title {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
.search-result-file-matches {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
.search-result-file-title:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.search-result-file-match:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
/* Folder arrow */
|
||||
.nav-folder.is-collapsed .nav-folder-collapse-indicator {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
.nav-folder-collapse-indicator {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
/* Tag Selection */
|
||||
.tag-pane-tag:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-light .tag-pane-tag-count {
|
||||
color: var(--text-normal)
|
||||
}
|
||||
|
||||
/* Title */
|
||||
.side-dock-title {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
/* Ribon */
|
||||
.side-dock-ribbon {
|
||||
background-color: #3e3471!important;
|
||||
color: var(--text-muted)
|
||||
}
|
||||
|
||||
.side-dock-ribbon-tab, .side-dock-ribbon-action {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-dark .side-dock-ribbon-tab.is-active {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-dark .side-dock-ribbon-tab.is-before-active {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-light .side-dock-ribbon-tab.is-active {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
.theme-light .side-dock-ribbon-tab.is-before-active {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.side-dock-ribbon-tab-inner {
|
||||
color: unset;
|
||||
}
|
||||
|
||||
.side-dock-ribbon-before.is-before-active .side-dock-ribbon-tab-inner, .side-dock-ribbon-after.is-after-active .side-dock-ribbon-tab-inner, .side-dock-ribbon-tab.is-before-active .side-dock-ribbon-tab-inner, .side-dock-ribbon-tab.is-after-active .side-dock-ribbon-tab-inner {
|
||||
background-color: #3e3471;
|
||||
}
|
||||
|
||||
.side-dock-ribbon-tab, .side-dock-ribbon-before, .side-dock-ribbon-after, .side-dock-ribbon-tab-inner {
|
||||
transition: none;
|
||||
}
|
||||
|
||||
/**/
|
||||
/* Settings panel Section */
|
||||
/**/
|
||||
.vertical-tab-nav-item.is-active {
|
||||
background-color: #3e3471;
|
||||
color:white;
|
||||
}
|
||||
|
||||
.horizontal-tab-nav-item:hover, .vertical-tab-nav-item:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.vertical-tab-nav-item.is-active {
|
||||
background-color: #3e3471;
|
||||
}
|
||||
|
||||
.vertical-tab-nav-item.is-active {
|
||||
border-left-color: #3e3471;
|
||||
}
|
||||
@@ -0,0 +1,41 @@
|
||||
# The Methodology
|
||||
The P.A.R.A system is surprisingly simple at first glance but very powerful when applied. At its core, it's just a four folder wide hierarchy with four-layer deeps, starting with those four root folders:
|
||||
|
||||
1. Projects
|
||||
2. Areas
|
||||
3. Resources
|
||||
4. Archive
|
||||
|
||||
From there, each of the roots is allowed one sub-folder level and then notes. That's how the four levels deep work: App (1) -> `1. Projects` (2) -> P.A.R.A. Demo Vault (3) -> Methodology (4). The reason for this is to keep it manageable and easy to remember and navigate. That restriction was initially because of Evernote limitation, but it turns out to have some serendipity potential. By putting all your notes from similar "zone" and actionability together, you end up with many serendipitous findings of new related notes and ideas.
|
||||
|
||||
Just those root folders and their children, the system can contain everything most people needs for their notes and files. This taxonomy works because you don't split things based on categories but actionability and areas of your life. So now, let's define those roots to help see how it works.
|
||||
|
||||
## Definition
|
||||
1. Projects: *Every current project that is actionable with its notes, files, artifacts*
|
||||
- If you have a project that requires notes or files, it should have a folder in 1. Projects.
|
||||
- Since this folder is for projects you are working on _right now_, it's the most actionable and probably where you will spend most of your time.
|
||||
2. Areas: *Zone of responsibility with standard to uphold over long periods*, parent, animals, management, coding, house.
|
||||
- Areas are **the personal** bucket of your life for important things that don't have an end date. You won't ever "stop" working on your health; for example, it's a constant ongoing thing.
|
||||
- While areas can (and often do) generate projects, they are not linked since it's already intuitive which areas a project comes from, so there's no need to create an explicit link between, for example, the "Server maintenance" project and the "Sysadmin" area.
|
||||
- Finally, because they are personal, areas contain information you wrote for _yourself only_ about those areas in your life. Which is opposite to 3. Resources.
|
||||
3. Resources: *Zone of interest for various topics that don't require standard/responsibility*, game, cooking, productivity, technology.
|
||||
- Resources are **generally helpful for others**, not just you. For example, if someone was to ask you for information about cooking, you could zip that folder and send it to them.
|
||||
- The folders in there will very often reflect your various interests, what you're curious about and want to learn more about.
|
||||
- They are not necessarily actual "resources" as in PDF, Pictures, etc. they can also be notes about those subjects
|
||||
4. Archives: *Where stuff from all the other category become unused*, finished project, change of responsibility, etc.
|
||||
- This folder will be where you put things you won't need for a while, as the name suggests. For the most part, something in there won't be seen for a time, and that's why it has the lowest actionability, but sometimes a new project could use things in there, or a change of areas might mean you need to get stuff out of there.
|
||||
- For example, you have lots of notes on living with a pet in a small apartment, and then you move to a new bigger one. You could move all those to the archive if one day you have to go back to a small apartment again take them out.
|
||||
|
||||
## Setup
|
||||
The setup for it is pretty simple, create root folders for each category, like in this sandbox. From there, move all of your current notes into `4. Archives` as is with the same existing hierarchy (remember it's not deleted 😉). Then create one folder for each of your current projects you're working on in `1. Projects` (remember only one sub-folder to stay four levels deep). For `2. Areas`, if you already know some of them, you can create the folders already, but try not to have too many empty folders. Finally, `3. Resources`, you want to stay empty for now unless you already captured things that could go in it. The idea is that each time you go into `4. Archives` to take one of the "old" notes or files, you then move it to the right spot in the new taxonomy. Doing it this way will highlight the most used notes, and what's left behind can stay in Archive until it's finally used (or not).
|
||||
|
||||
Once you have the folder hierarchy done, you want to copy it across all your other systems; that is where P.A.R.A. starts to shine. You want to have the same hierarchy for your local files on your computer, in your notes, in your Dropbox/Google Drive/iCloud, and everywhere else you have to keep information. Doing that will make it very quick and easy to find things you might need for work or something in the same zone across all your apps. For this reason, the more system you integrate the taxonomy into, the easier finding things will be.
|
||||
|
||||
### Setup tips:
|
||||
- If a note (or a file) can go into two different folders, you put it in the folder where you will **_most likely need it next_** since folders are based on actionability, and it will get moved anyway in the flow of things.
|
||||
- You can also have the "same" folder in 2 different roots. For example, `2. Areas/Health` and `3. Resources/Health` the first one is **_your_** health notes and the other **general** health-related notes.
|
||||
- Remember, you do **_not_** want to sort all your current notes and files and put them in the new folder, put them all in the Archive as is, and then move them out as you use them.
|
||||
- You do **_not_** have to do every single folder for your local files and cloud service; create the sub-folders are you need them, **_but_** you need to have one complete setup, most likely in your notes, to act as the primary reference for the others.
|
||||
|
||||
|
||||
# Next stop [[Workflows]]
|
||||
@@ -0,0 +1,22 @@
|
||||
## Start here
|
||||
- General how-this-work
|
||||
- What to expect
|
||||
- How to start
|
||||
## Definition
|
||||
- Projects: Short-term efforts with a clear outcome
|
||||
- Areas: Long-term responsibilities to maintain
|
||||
- Resources: Topics or interests useful in the future
|
||||
- Archives: Inactive items from other categories
|
||||
## Methodology
|
||||
- Actionnability
|
||||
- Fluidity
|
||||
- Project based
|
||||
- Constraint
|
||||
## Workflow
|
||||
- Capture: Collect everything in Inbox
|
||||
- Clarify: Determine if it's a Project, Area, Resource, or Archive
|
||||
- Organize: Move to appropriate PARA folder
|
||||
- Review: Regular reviews to maintain system
|
||||
## Next steps
|
||||
- Tiago's blog
|
||||
- Discord
|
||||
@@ -0,0 +1,25 @@
|
||||
# How to use this for work
|
||||
The workflow of P.A.R.A. is based on projects, as they are the most actionable information, but the information also flows in other ways. Most of the flowing and moving in the system will happen when you use the notes or when you are done with a project; that's why starting and finishing projects are crucial moments. As notes can flow to/from each part of the P.A.R.A, it's best to show with examples:
|
||||
|
||||
## Example 1 - Project
|
||||
This example is the "normal" workflow for most things. First, you start with a project, something like writing this starter kit.
|
||||
|
||||
You first create the folder for the project once you're ready. Then you go around `2. Areas` and `3. Resources` to find the information possibly useful for the project; in this case, I would look in my `Second Brain` folder and my `Personal Knowledge Management` folder. From there starts the first flow, you take those notes, pictures, etc., and put them in the folder. At this point, you use them to create the product and complete the project.
|
||||
|
||||
Once the project is over, the 2nd flow can start; it's time to look at all the notes and artifacts you created and used. For each of them, see if they would still be helpful later if they could be turned into a template or formatted more generically. The idea is to keep those around for use in other projects later, so put them in the correct `2. Areas` folder. The remainder goes into `4. Archives`.
|
||||
|
||||
## Example 2 - Areas change
|
||||
You decided to change your job and launch your own business in a completely different field. That would mean most of the information in your job-related `2. Areas` would not be actionable anymore. So now you can look if some things in that area could still be helpful and move the rest to `4. Archives`.
|
||||
|
||||
If a couple of months later something comes up and it forces you to get back into that first field, take the folder out of `4. Archives` and put it back into `2. Areas`, and you're back into business just like before.
|
||||
|
||||
## Example 3 - Resource change
|
||||
Since things in `3. Resources` interest you to learn more about it can be that it changes at some point. A resource folder on `Marketing`, for example, could turn into a freelance job in marketing.
|
||||
|
||||
When that happens, you now have a standard to uphold (freelance standard), so you create a new folder in `2. Areas` for "Marketing" and move all the notes you wrote yourself from `3. Resources` into that new one (since `2. Areas` is for things you wrote yourself)
|
||||
|
||||
|
||||
# Next step Explore!
|
||||
You're officially done with the explanation now; you can proceed to try it for yourself or explore more around. If you have questions, don't hesitate to ask on the forum thread or read the [P.A.R.A. complete article](https://fortelabs.co/blog/para/) for a deeper dive into all the details.
|
||||
|
||||
If you want to look at more demo vaults like this, I also have my own system, a fork of P.A.R.A. for my use over [here](https://forum.obsidian.md/t/paan-starter-kit/21782). Finally, for more general writing, I have my blog where I will often write about that system or others at [maximecote.me](https://maximecote.me/)
|
||||
@@ -0,0 +1,3 @@
|
||||
- **Areas are ==**personal**==** to you, Resources are ==**generally useful for others**==
|
||||
- Just move the note in the right place do not file them or change them
|
||||
- You can always split notebook if they become too big
|
||||
@@ -0,0 +1,2 @@
|
||||
- Let's make it fun and it's going to be easier too
|
||||
- ==If you don't have at least one new project or one archived project or one split/merge project in a week you need to question the size of them==
|
||||
@@ -0,0 +1 @@
|
||||
According to biographer Claire Tomalin, Dickens crafted much of the tale in his head while engaged in nighttime walks that covered 15 to 20 miles. As a result of this ambulatory cogitation, the entire story took only six weeks to complete in the late fall of 1843.
|
||||
@@ -0,0 +1,2 @@
|
||||
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
List:
|
||||
- New application features and menu
|
||||
- Focus mode for the current line
|
||||
- Focus UI for writing
|
||||
@@ -0,0 +1,365 @@
|
||||
/* Special Font */
|
||||
body, p {
|
||||
font-family: "Dank Mono",'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Microsoft YaHei Light", sans-serif;
|
||||
}
|
||||
|
||||
.cm-s-obsidian {
|
||||
font-family: "Dank Mono",'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Microsoft YaHei Light", sans-serif;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
.editor {
|
||||
font-family: "Dank Mono",'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Microsoft YaHei Light", sans-serif;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
.markdown-preview-view code {
|
||||
font-family: "Dank Mono",'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Microsoft YaHei Light", sans-serif;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
.preview {
|
||||
font-family: "Dank Mono",'Inter', -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Microsoft YaHei Light", sans-serif;
|
||||
font-size: 16px;
|
||||
}
|
||||
|
||||
/* Scrollbar */
|
||||
::-webkit-scrollbar {
|
||||
background-color: transparent;
|
||||
}
|
||||
|
||||
/**/
|
||||
/* Editor Section */
|
||||
/**/
|
||||
/* Line size */
|
||||
.cm-s-obsidian pre.HyperMD-header {
|
||||
line-height: 1!important;
|
||||
}
|
||||
|
||||
/* Selection */
|
||||
.theme-light {
|
||||
--text-selection: rgba(112, 93, 207, 0.5);
|
||||
}
|
||||
|
||||
.theme-dark {
|
||||
--text-selection: rgba(112, 93, 207, 0.5);
|
||||
}
|
||||
|
||||
::selection {
|
||||
background-color: #705dcf;
|
||||
color: white;
|
||||
}
|
||||
|
||||
/* Title */
|
||||
/* Current main pane */
|
||||
.view-header-title {
|
||||
color: #705dcf;
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
.workspace-leaf.mod-active .view-header {
|
||||
text-align: center;
|
||||
}
|
||||
/* Other pane */
|
||||
.workspace-leaf-header-title-container {
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
/* Headers */
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-1.cm-header.cm-header-1 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-2.cm-header.cm-header-2 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-3.cm-header.cm-header-3 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-4.cm-header.cm-header-4 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-5.cm-header.cm-header-5 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
span.cm-formatting.cm-formatting-header.cm-formatting-header-6.cm-header.cm-header-6 {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
/* Header folder icon */
|
||||
.CodeMirror-foldgutter-open, .CodeMirror-foldgutter-folded {
|
||||
color: #3e3471;
|
||||
}
|
||||
|
||||
.CodeMirror-foldgutter-open, .CodeMirror-foldgutter-folded {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
/* Cursor */
|
||||
.cm-fat-cursor .CodeMirror-cursor {
|
||||
background: #3e3471;
|
||||
}
|
||||
|
||||
.cm-animate-fat-cursor {
|
||||
background-color: #3e3471;
|
||||
}
|
||||
|
||||
/* Selection in popup ([[]] autocomplete)*/
|
||||
.suggestion-item.is-selected {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-light .suggestion-shortcut {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
/* Inner and Outer links */
|
||||
.cm-url {
|
||||
color: lightblue!important;
|
||||
}
|
||||
|
||||
.markdown-highlighting .internal-link .cl-underlined-text {
|
||||
color: var(--text-accent)!important;
|
||||
}
|
||||
|
||||
.markdown-highlighting .link .cl-underlined-text {
|
||||
color: lightblue!important;
|
||||
}
|
||||
|
||||
/* Blockquote */
|
||||
.preview blockquote {
|
||||
background-color: var(--background-modifier-border);
|
||||
border: 1px solid var(--text-muted);
|
||||
}
|
||||
|
||||
/* Highlights and Bold */
|
||||
strong {
|
||||
font-size: larger;
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
mark {
|
||||
background-color: darkgoldenrod;
|
||||
}
|
||||
|
||||
.markdown-highlighting .tag {
|
||||
color: var(--text-accent)!important;
|
||||
}
|
||||
|
||||
/* Tables */
|
||||
.markdown-preview-view th {
|
||||
background-color: #3e3471;
|
||||
color: white
|
||||
}
|
||||
|
||||
.cm-s-obsidian pre.HyperMD-table-row span.cm-hmd-table-sep {
|
||||
color: unset;
|
||||
}
|
||||
|
||||
.cm-s-obsidian pre.HyperMD-table-row-1 > span {
|
||||
color: unset;
|
||||
}
|
||||
|
||||
/* Status bar */
|
||||
.theme-dark .status-bar-item {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-light .status-bar-item {
|
||||
color: black;
|
||||
}
|
||||
|
||||
/**/
|
||||
/* Preview section */
|
||||
/**/
|
||||
/* Centered preview */
|
||||
.markdown-preview-view
|
||||
{
|
||||
padding-left: 10% !important;
|
||||
padding-right: 10% !important;
|
||||
}
|
||||
|
||||
.markdown-embed-title {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
.markdown-preview-view .markdown-embed {
|
||||
background-color: var(--background-primary-alt);
|
||||
margin-top: 0.5rem;
|
||||
margin-bottom: 0.5rem;
|
||||
}
|
||||
|
||||
.markdown-preview-view .internal-link {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
.markdown-preview-view a {
|
||||
color: lightblue;
|
||||
}
|
||||
|
||||
/**/
|
||||
/* Side panel section */
|
||||
/**/
|
||||
/* Plugin Title and Description */
|
||||
.plugin-name {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
.plugin-description {
|
||||
color: var(--text-normal)
|
||||
}
|
||||
|
||||
/* Files title and Buttons */
|
||||
.nav-file-title-content, .nav-folder-title-content {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
.nav-action-button {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
/* File explorer navigation selection */
|
||||
.nav-file.is-active > .nav-file-title, .nav-file.is-active > .nav-folder-title, .nav-file.is-active > .nav-folder-collapse-indicator, .nav-folder.is-active > .nav-file-title, .nav-folder.is-active > .nav-folder-title, .nav-folder.is-active > .nav-folder-collapse-indicator {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
body:not(.is-grabbing) .nav-file-title:hover, body:not(.is-grabbing) .nav-folder-title:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.nav-file-title-content, .nav-folder-title-content {
|
||||
color:unset;
|
||||
}
|
||||
|
||||
.nav-folder.mod-root > .nav-file-title:hover, .nav-folder.mod-root > .nav-folder-title:hover {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
body:not(.is-grabbing) .nav-file-title:hover .nav-folder-collapse-indicator, body:not(.is-grabbing) .nav-folder-title:hover .nav-folder-collapse-indicator {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.nav-file-title, .nav-folder-title, .nav-folder-collapse-indicator {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
/* File explorer menu*/
|
||||
.menu-item:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
/* Backlinks Color and Text */
|
||||
.search-result-file-matched-text {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.search-result-file-title {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
.search-result-file-matches {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
.search-result-file-title:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.search-result-file-match:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
/* Folder arrow */
|
||||
.nav-folder.is-collapsed .nav-folder-collapse-indicator {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
.nav-folder-collapse-indicator {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
/* Tag Selection */
|
||||
.tag-pane-tag:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-light .tag-pane-tag-count {
|
||||
color: var(--text-normal)
|
||||
}
|
||||
|
||||
/* Title */
|
||||
.side-dock-title {
|
||||
color: #705dcf;
|
||||
}
|
||||
|
||||
/* Ribon */
|
||||
.side-dock-ribbon {
|
||||
background-color: #3e3471!important;
|
||||
color: var(--text-muted)
|
||||
}
|
||||
|
||||
.side-dock-ribbon-tab, .side-dock-ribbon-action {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-dark .side-dock-ribbon-tab.is-active {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-dark .side-dock-ribbon-tab.is-before-active {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.theme-light .side-dock-ribbon-tab.is-active {
|
||||
color: var(--text-normal);
|
||||
}
|
||||
|
||||
.theme-light .side-dock-ribbon-tab.is-before-active {
|
||||
color: white;
|
||||
}
|
||||
|
||||
.side-dock-ribbon-tab-inner {
|
||||
color: unset;
|
||||
}
|
||||
|
||||
.side-dock-ribbon-before.is-before-active .side-dock-ribbon-tab-inner, .side-dock-ribbon-after.is-after-active .side-dock-ribbon-tab-inner, .side-dock-ribbon-tab.is-before-active .side-dock-ribbon-tab-inner, .side-dock-ribbon-tab.is-after-active .side-dock-ribbon-tab-inner {
|
||||
background-color: #3e3471;
|
||||
}
|
||||
|
||||
.side-dock-ribbon-tab, .side-dock-ribbon-before, .side-dock-ribbon-after, .side-dock-ribbon-tab-inner {
|
||||
transition: none;
|
||||
}
|
||||
|
||||
/**/
|
||||
/* Settings panel Section */
|
||||
/**/
|
||||
.vertical-tab-nav-item.is-active {
|
||||
background-color: #3e3471;
|
||||
color:white;
|
||||
}
|
||||
|
||||
.horizontal-tab-nav-item:hover, .vertical-tab-nav-item:hover {
|
||||
background-color: #3e3471;
|
||||
color: white;
|
||||
}
|
||||
|
||||
.vertical-tab-nav-item.is-active {
|
||||
background-color: #3e3471;
|
||||
}
|
||||
|
||||
.vertical-tab-nav-item.is-active {
|
||||
border-left-color: #3e3471;
|
||||
}
|
||||
@@ -0,0 +1,3 @@
|
||||
- areas are usually the overhead in the background (maintenance, support, upgrade etc)
|
||||
- projects are finite and clean they have a concrete outcome/package/deliverable
|
||||
- areas and resources can be more aspirational and dreams mostly things you want to start to take notes on interest are like plane on your radar they come and go and come back later
|
||||
@@ -0,0 +1,44 @@
|
||||
|
||||
## P.A.R.A
|
||||
P.rojects
|
||||
A.reas
|
||||
R.esources
|
||||
A.rchive
|
||||
|
||||
## Definitions
|
||||
- Projects => Every current projects (see def. below) that are actionable with their notes, files, artifacts
|
||||
- Areas => Zone of responsibility with standard to uphold over long periods, parent, animals, management, coding, house
|
||||
- Resources => Zone of interest for various topics that don’t require standard/responsibility, game, phone, productivity, self development, technology
|
||||
- Archive => Where things from all the other category become unused, finished, change of responsibility etc
|
||||
|
||||
A project is something with a goal and a deadline that requires more than 1 step to complete
|
||||
A project packet is an intermediate step before the completion that is itself a “thing” made and that could be reused or serves as a snapshot of progress
|
||||
|
||||
## Workflow
|
||||
### Projects flow
|
||||
Project -> Areas -> Resources -> Archive
|
||||
|
||||
Project -> AreasA project turned into something more after finishing it. Eg. new responsibility over the thing made, new job opportunity etc
|
||||
Project -> ResourcesA part of the project packet or the thing made could be reused in other ways later. Eg. PowerPoint layout, book resume, study notes etc
|
||||
Project -> ArchiveOnce the project is finished, areas and resources information or packet have been moved what’s left goes into archive for conservation and possible reuse later
|
||||
|
||||
### Areas flow
|
||||
Project <- Areas -> Resources -> Archive
|
||||
|
||||
Areas -> Project
|
||||
Areas -> Resources
|
||||
Areas -> Archive
|
||||
|
||||
### Resources flow
|
||||
Project <- Areas <- Resources -> Archive
|
||||
|
||||
Resources -> Project
|
||||
Resources -> Areas
|
||||
Resources -> Archive
|
||||
|
||||
### Archive flow
|
||||
Project <- Areas <- Resources <- Archive
|
||||
|
||||
Archive -> Project
|
||||
Archive -> Areas
|
||||
Archive -> Resources
|
||||
@@ -0,0 +1,41 @@
|
||||
# The Methodology
|
||||
The P.A.R.A system is surprisingly simple at first glance but very powerful when applied. At its core, it's just a four folder wide hierarchy with four-layer deeps, starting with those four root folders:
|
||||
|
||||
1. Projects
|
||||
2. Areas
|
||||
3. Resources
|
||||
4. Archive
|
||||
|
||||
From there, each of the roots is allowed one sub-folder level and then notes. That's how the four levels deep work: App (1) -> `1. Projects` (2) -> P.A.R.A. Demo Vault (3) -> Methodology (4). The reason for this is to keep it manageable and easy to remember and navigate. That restriction was initially because of Evernote limitation, but it turns out to have some serendipity potential. By putting all your notes from similar "zone" and actionability together, you end up with many serendipitous findings of new related notes and ideas.
|
||||
|
||||
Just those root folders and their children, the system can contain everything most people needs for their notes and files. This taxonomy works because you don't split things based on categories but actionability and areas of your life. So now, let's define those roots to help see how it works.
|
||||
|
||||
## Definition
|
||||
1. Projects: *Every current project that is actionable with its notes, files, artifacts*
|
||||
- If you have a project that requires notes or files, it should have a folder in 1. Projects.
|
||||
- Since this folder is for projects you are working on _right now_, it's the most actionable and probably where you will spend most of your time.
|
||||
2. Areas: *Zone of responsibility with standard to uphold over long periods*, parent, animals, management, coding, house.
|
||||
- Areas are **the personal** bucket of your life for important things that don't have an end date. You won't ever "stop" working on your health; for example, it's a constant ongoing thing.
|
||||
- While areas can (and often do) generate projects, they are not linked since it's already intuitive which areas a project comes from, so there's no need to create an explicit link between, for example, the "Server maintenance" project and the "Sysadmin" area.
|
||||
- Finally, because they are personal, areas contain information you wrote for _yourself only_ about those areas in your life. Which is opposite to 3. Resources.
|
||||
3. Resources: *Zone of interest for various topics that don't require standard/responsibility*, game, cooking, productivity, technology.
|
||||
- Resources are **generally helpful for others**, not just you. For example, if someone was to ask you for information about cooking, you could zip that folder and send it to them.
|
||||
- The folders in there will very often reflect your various interests, what you're curious about and want to learn more about.
|
||||
- They are not necessarily actual "resources" as in PDF, Pictures, etc. they can also be notes about those subjects
|
||||
4. Archives: *Where stuff from all the other category become unused*, finished project, change of responsibility, etc.
|
||||
- This folder will be where you put things you won't need for a while, as the name suggests. For the most part, something in there won't be seen for a time, and that's why it has the lowest actionability, but sometimes a new project could use things in there, or a change of areas might mean you need to get stuff out of there.
|
||||
- For example, you have lots of notes on living with a pet in a small apartment, and then you move to a new bigger one. You could move all those to the archive if one day you have to go back to a small apartment again take them out.
|
||||
|
||||
## Setup
|
||||
The setup for it is pretty simple, create root folders for each category, like in this sandbox. From there, move all of your current notes into `4. Archives` as is with the same existing hierarchy (remember it's not deleted 😉). Then create one folder for each of your current projects you're working on in `1. Projects` (remember only one sub-folder to stay four levels deep). For `2. Areas`, if you already know some of them, you can create the folders already, but try not to have too many empty folders. Finally, `3. Resources`, you want to stay empty for now unless you already captured things that could go in it. The idea is that each time you go into `4. Archives` to take one of the "old" notes or files, you then move it to the right spot in the new taxonomy. Doing it this way will highlight the most used notes, and what's left behind can stay in Archive until it's finally used (or not).
|
||||
|
||||
Once you have the folder hierarchy done, you want to copy it across all your other systems; that is where P.A.R.A. starts to shine. You want to have the same hierarchy for your local files on your computer, in your notes, in your Dropbox/Google Drive/iCloud, and everywhere else you have to keep information. Doing that will make it very quick and easy to find things you might need for work or something in the same zone across all your apps. For this reason, the more system you integrate the taxonomy into, the easier finding things will be.
|
||||
|
||||
### Setup tips:
|
||||
- If a note (or a file) can go into two different folders, you put it in the folder where you will **_most likely need it next_** since folders are based on actionability, and it will get moved anyway in the flow of things.
|
||||
- You can also have the "same" folder in 2 different roots. For example, `2. Areas/Health` and `3. Resources/Health` the first one is **_your_** health notes and the other **general** health-related notes.
|
||||
- Remember, you do **_not_** want to sort all your current notes and files and put them in the new folder, put them all in the Archive as is, and then move them out as you use them.
|
||||
- You do **_not_** have to do every single folder for your local files and cloud service; create the sub-folders are you need them, **_but_** you need to have one complete setup, most likely in your notes, to act as the primary reference for the others.
|
||||
|
||||
|
||||
# Next stop [[Workflows]]
|
||||
@@ -0,0 +1,22 @@
|
||||
## Start here
|
||||
- General how-this-work
|
||||
- What to expect
|
||||
- How to start
|
||||
## Definition
|
||||
- Projects: Short-term efforts with a clear outcome
|
||||
- Areas: Long-term responsibilities to maintain
|
||||
- Resources: Topics or interests useful in the future
|
||||
- Archives: Inactive items from other categories
|
||||
## Methodology
|
||||
- Actionnability
|
||||
- Fluidity
|
||||
- Project based
|
||||
- Constraint
|
||||
## Workflow
|
||||
- Capture: Collect everything in Inbox
|
||||
- Clarify: Determine if it's a Project, Area, Resource, or Archive
|
||||
- Organize: Move to appropriate PARA folder
|
||||
- Review: Regular reviews to maintain system
|
||||
## Next steps
|
||||
- Tiago's blog
|
||||
- Discord
|
||||
@@ -0,0 +1,39 @@
|
||||
# PKM Content Organization - Decision Note
|
||||
|
||||
## Analysis (2025-12-29)
|
||||
|
||||
After reviewing both locations containing PARA methodology content:
|
||||
- **[300-resources/Personal Knowledge Management](300-resources/Personal Knowledge Management)** - 8 files (course notes, references, essays)
|
||||
- **[100-project/Personal/PKM/PARA](100-project/Personal/PKM/PARA)** - 3 files (implementation guide)
|
||||
|
||||
## Decision: Keep Current Structure
|
||||
|
||||
**Rationale:**
|
||||
1. **Different purposes, complementary content:**
|
||||
- `300-resources/PKM/` contains **source material** from BASB courses, external essays, and learning references
|
||||
- `100-project/PKM/PARA/` contains **implementation documentation** specific to this vault's setup
|
||||
|
||||
2. **PARA principle alignment:**
|
||||
- Resources = generally useful reference material (course notes, methodology explanations)
|
||||
- Projects = active work on implementing/customizing the system
|
||||
|
||||
3. **Content breakdown:**
|
||||
- **300-resources/PKM/** (Reference material):
|
||||
- BASB Class 7 & 8 notes (course content)
|
||||
- PARA Notes.md & PARA Notes from class.md (methodology reference)
|
||||
- Gregory Gundersen essay (writing philosophy)
|
||||
- Dickens deep work (anecdote)
|
||||
- Images.md (visual references)
|
||||
|
||||
- **100-project/PKM/PARA/** (Implementation):
|
||||
- Methodology.md (how to apply in Obsidian)
|
||||
- Workflows.md (practical examples for this vault)
|
||||
- Outline.md (project plan)
|
||||
|
||||
## Cleanup Actions Taken
|
||||
|
||||
✅ Moved arc42 from `300-resources/PKM/` to `300-resources/Development/Architecture/` (was misplaced)
|
||||
|
||||
## Recommendation
|
||||
|
||||
No merge needed. The two locations serve distinct purposes and should remain separate. If PKM project becomes inactive, move implementation docs to `200-area/Personal Development/` (ongoing learning responsibility) and keep course references in `300-resources/`.
|
||||
@@ -0,0 +1,25 @@
|
||||
# How to use this for work
|
||||
The workflow of P.A.R.A. is based on projects, as they are the most actionable information, but the information also flows in other ways. Most of the flowing and moving in the system will happen when you use the notes or when you are done with a project; that's why starting and finishing projects are crucial moments. As notes can flow to/from each part of the P.A.R.A, it's best to show with examples:
|
||||
|
||||
## Example 1 - Project
|
||||
This example is the "normal" workflow for most things. First, you start with a project, something like writing this starter kit.
|
||||
|
||||
You first create the folder for the project once you're ready. Then you go around `2. Areas` and `3. Resources` to find the information possibly useful for the project; in this case, I would look in my `Second Brain` folder and my `Personal Knowledge Management` folder. From there starts the first flow, you take those notes, pictures, etc., and put them in the folder. At this point, you use them to create the product and complete the project.
|
||||
|
||||
Once the project is over, the 2nd flow can start; it's time to look at all the notes and artifacts you created and used. For each of them, see if they would still be helpful later if they could be turned into a template or formatted more generically. The idea is to keep those around for use in other projects later, so put them in the correct `2. Areas` folder. The remainder goes into `4. Archives`.
|
||||
|
||||
## Example 2 - Areas change
|
||||
You decided to change your job and launch your own business in a completely different field. That would mean most of the information in your job-related `2. Areas` would not be actionable anymore. So now you can look if some things in that area could still be helpful and move the rest to `4. Archives`.
|
||||
|
||||
If a couple of months later something comes up and it forces you to get back into that first field, take the folder out of `4. Archives` and put it back into `2. Areas`, and you're back into business just like before.
|
||||
|
||||
## Example 3 - Resource change
|
||||
Since things in `3. Resources` interest you to learn more about it can be that it changes at some point. A resource folder on `Marketing`, for example, could turn into a freelance job in marketing.
|
||||
|
||||
When that happens, you now have a standard to uphold (freelance standard), so you create a new folder in `2. Areas` for "Marketing" and move all the notes you wrote yourself from `3. Resources` into that new one (since `2. Areas` is for things you wrote yourself)
|
||||
|
||||
|
||||
# Next step Explore!
|
||||
You're officially done with the explanation now; you can proceed to try it for yourself or explore more around. If you have questions, don't hesitate to ask on the forum thread or read the [P.A.R.A. complete article](https://fortelabs.co/blog/para/) for a deeper dive into all the details.
|
||||
|
||||
If you want to look at more demo vaults like this, I also have my own system, a fork of P.A.R.A. for my use over [here](https://forum.obsidian.md/t/paan-starter-kit/21782). Finally, for more general writing, I have my blog where I will often write about that system or others at [maximecote.me](https://maximecote.me/)
|
||||
@@ -0,0 +1,5 @@
|
||||
### Notes
|
||||
```dataview
|
||||
table file.ctime as Date from "300-resources/Personal Knowledge Management"
|
||||
sort file.name
|
||||
```
|
||||
+53
@@ -0,0 +1,53 @@
|
||||
http://gregorygundersen.com/blog/2020/01/12/why-research-blog/
|
||||
|
||||
Before I started taking writing seriously, I had a loose grasp of many mathematical and technical concepts; and I was not sure how to tackle open-ended problem
|
||||
|
||||
I learned very early the difference between knowing the name of something and knowing something.
|
||||
|
||||
When I write a blog post, I imagine my supervisor, a respected
|
||||
colleague, or a future employer reading my explanation. These imagined readers force me to ask myself honestly if I understand what I am writing.
|
||||
|
||||
The end result is that writing forces me to acknowledge and then work through my confusion.
|
||||
|
||||
Summarizing a paper in your own words restructures the content to focus on learning rather than novelty.
|
||||
|
||||
A side effect of having written detailed technical notes is that I
|
||||
calibrate my confidence on a topic. If I now understand something, I am sure of it and can explain myself clearly. If I don't understand something, I have a sense of why it is difficult to understand or what prerequisite knowledge I am missing.
|
||||
|
||||
For me, writing things down is the best way I have found to ensure that I actually do the work.
|
||||
|
||||
Blogging has taught me how to read a paper because explaining something is a more active form of understanding
|
||||
|
||||
This process mimics the act of presenting and is great practice for it.
|
||||
|
||||
However, with proficiency came creativity. Programming became less important than what I was building and why. When I started my PhD, I hypothesized that the same rules would apply: I wouldn't be able to think creatively about machine learning until I built up the requisite knowledge base. In programming, you can practice by writing programs; but how can you practice research? For me, writing detailed, expository technical notes is the equivalent of the programmer's side project: it forces me to intentionally and systematically build my knowledge base by understanding ideas, working through proofs, and implementing models.
|
||||
|
||||
My understanding and confidence in the material changed profoundly. I became intellectually committed in a way that was impossible without first understanding the problem
|
||||
|
||||
Under pressure, my mind, like a cart on a well-worn path, finds the same old ruts. Once again, writing breaks this cycle because it requires more active participation.
|
||||
|
||||
Hard problems are intimidating; and I often do not know where to start and am worried that I will waste my time. Writing blog posts about the larger context of a problem is my way of flanking it, of head faking myself about what I am actually doing. This lowers the psychological stakes because, rather than directly attacking the problem, I am producing something that I know will be valuable either way.
|
||||
|
||||
These posts, written in the spring and summer, allowed me to start thinking about and preparing for the problem indirectly.
|
||||
|
||||
However, writing is my other way of mitigating risk. If my current
|
||||
project were to fail, the directed and intentional process of
|
||||
systematically attacking the background material will have prepared me well for the next problem.
|
||||
|
||||
If you don't see that what you are working on is almost obvious, then you are not ready to work on that yet.
|
||||
|
||||
I find this quote comforting because it suggests that good ideas---at least for one famous mathematician---do not come into the mind ex niliho. Rather, good ideas come from so deeply understanding a problem that the solution seems obvious.
|
||||
|
||||
In my own experience, writing has gotten me closer than anything else to having original research thoughts that feel obvious.
|
||||
|
||||
By understanding problems deeply, you increase the probability that you can work on an important, attackable problem.
|
||||
|
||||
I think of writing-as-learning as database indexing. In a database, an index is a data structure that efficiently keeps track of where rows in a table are located. To insert into a database via an index is slower than simply adding the row to the bottom of the table because the database must do some bookkeeping. However, querying a database is extremely efficient. A layperson's example is organizing your books alphabetically.
|
||||
|
||||
Importantly, I had forgotten if the relationship were true, but it felt correct, and I knew exactly where to look to confirm my guess.
|
||||
|
||||
Maybe one thing I appreciate more now is that the state of human knowledge is full of holes. When you're young you have the impression that almost everything is known, but now I have this feeling that almost everything is unknown about mathematics. There are these very thin channels that people have gone along, like ants following each other along a trail. You find these long thin trails of things, and most things are undeveloped. I have more of a sense of the openness of it.
|
||||
|
||||
In short, mathematics only exists in a living community of
|
||||
mathematicians that spreads understanding and breaths life into ideas both old and new. The real satisfaction from mathematics is in learning from others and sharing with others. All of us have clear understanding of a few things and murky concepts of many more. There is no way to run out of ideas in need of clarification. The question of who is the first person to ever set foot on some square meter of land is really secondary. Revolutionary change does matter, but revolutions are few,
|
||||
and they are not self-sustaining --- they depend very heavily on the community of mathematicians.
|
||||
@@ -0,0 +1,989 @@
|
||||
#
|
||||
|
||||
**About arc42**
|
||||
|
||||
arc42, the template for documentation of software and system
|
||||
architecture.
|
||||
|
||||
Template Version 8.2 EN. (based upon AsciiDoc version), January 2023
|
||||
|
||||
Created, maintained and © by Dr. Peter Hruschka, Dr. Gernot Starke and
|
||||
contributors. See <https://arc42.org>.
|
||||
|
||||
::: note
|
||||
This version of the template contains some help and explanations. It is
|
||||
used for familiarization with arc42 and the understanding of the
|
||||
concepts. For documentation of your own system you use better the
|
||||
*plain* version.
|
||||
:::
|
||||
|
||||
# Introduction and Goals {#section-introduction-and-goals}
|
||||
|
||||
Describes the relevant requirements and the driving forces that software
|
||||
architects and development team must consider. These include
|
||||
|
||||
- underlying business goals,
|
||||
|
||||
- essential features,
|
||||
|
||||
- essential functional requirements,
|
||||
|
||||
- quality goals for the architecture and
|
||||
|
||||
- relevant stakeholders and their expectations
|
||||
|
||||
## Requirements Overview {#_requirements_overview}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
Short description of the functional requirements, driving forces,
|
||||
extract (or abstract) of requirements. Link to (hopefully existing)
|
||||
requirements documents (with version number and information where to
|
||||
find it).
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
From the point of view of the end users a system is created or modified
|
||||
to improve support of a business activity and/or improve the quality.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
Short textual description, probably in tabular use-case format. If
|
||||
requirements documents exist this overview should refer to these
|
||||
documents.
|
||||
|
||||
Keep these excerpts as short as possible. Balance readability of this
|
||||
document with potential redundancy w.r.t to requirements documents.
|
||||
|
||||
See [Introduction and Goals](https://docs.arc42.org/section-1/) in the
|
||||
arc42 documentation.
|
||||
|
||||
## Quality Goals {#_quality_goals}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
The top three (max five) quality goals for the architecture whose
|
||||
fulfillment is of highest importance to the major stakeholders. We
|
||||
really mean quality goals for the architecture. Don't confuse them with
|
||||
project goals. They are not necessarily identical.
|
||||
|
||||
Consider this overview of potential topics (based upon the ISO 25010
|
||||
standard):
|
||||
|
||||
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
You should know the quality goals of your most important stakeholders,
|
||||
since they will influence fundamental architectural decisions. Make sure
|
||||
to be very concrete about these qualities, avoid buzzwords. If you as an
|
||||
architect do not know how the quality of your work will be judged...
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
A table with quality goals and concrete scenarios, ordered by priorities
|
||||
|
||||
## Stakeholders {#_stakeholders}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
Explicit overview of stakeholders of the system, i.e. all person, roles
|
||||
or organizations that
|
||||
|
||||
- should know the architecture
|
||||
|
||||
- have to be convinced of the architecture
|
||||
|
||||
- have to work with the architecture or with code
|
||||
|
||||
- need the documentation of the architecture for their work
|
||||
|
||||
- have to come up with decisions about the system or its development
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
You should know all parties involved in development of the system or
|
||||
affected by the system. Otherwise, you may get nasty surprises later in
|
||||
the development process. These stakeholders determine the extent and the
|
||||
level of detail of your work and its results.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
Table with role names, person names, and their expectations with respect
|
||||
to the architecture and its documentation.
|
||||
|
||||
+-------------+---------------------------+---------------------------+
|
||||
| Role/Name | Contact | Expectations |
|
||||
+=============+===========================+===========================+
|
||||
| *\<Role-1>* | *\<Contact-1>* | *\<Expectation-1>* |
|
||||
+-------------+---------------------------+---------------------------+
|
||||
| *\<Role-2>* | *\<Contact-2>* | *\<Expectation-2>* |
|
||||
+-------------+---------------------------+---------------------------+
|
||||
|
||||
# Architecture Constraints {#section-architecture-constraints}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
Any requirement that constraints software architects in their freedom of
|
||||
design and implementation decisions or decision about the development
|
||||
process. These constraints sometimes go beyond individual systems and
|
||||
are valid for whole organizations and companies.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
Architects should know exactly where they are free in their design
|
||||
decisions and where they must adhere to constraints. Constraints must
|
||||
always be dealt with; they may be negotiable, though.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
Simple tables of constraints with explanations. If needed you can
|
||||
subdivide them into technical constraints, organizational and political
|
||||
constraints and conventions (e.g. programming or versioning guidelines,
|
||||
documentation or naming conventions)
|
||||
|
||||
See [Architecture Constraints](https://docs.arc42.org/section-2/) in the
|
||||
arc42 documentation.
|
||||
|
||||
# System Scope and Context {#section-system-scope-and-context}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
System scope and context - as the name suggests - delimits your system
|
||||
(i.e. your scope) from all its communication partners (neighboring
|
||||
systems and users, i.e. the context of your system). It thereby
|
||||
specifies the external interfaces.
|
||||
|
||||
If necessary, differentiate the business context (domain specific inputs
|
||||
and outputs) from the technical context (channels, protocols, hardware).
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
The domain interfaces and technical interfaces to communication partners
|
||||
are among your system's most critical aspects. Make sure that you
|
||||
completely understand them.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
Various options:
|
||||
|
||||
- Context diagrams
|
||||
|
||||
- Lists of communication partners and their interfaces.
|
||||
|
||||
See [Context and Scope](https://docs.arc42.org/section-3/) in the arc42
|
||||
documentation.
|
||||
|
||||
## Business Context {#_business_context}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
Specification of **all** communication partners (users, IT-systems, ...)
|
||||
with explanations of domain specific inputs and outputs or interfaces.
|
||||
Optionally you can add domain specific formats or communication
|
||||
protocols.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
All stakeholders should understand which data are exchanged with the
|
||||
environment of the system.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
All kinds of diagrams that show the system as a black box and specify
|
||||
the domain interfaces to communication partners.
|
||||
|
||||
Alternatively (or additionally) you can use a table. The title of the
|
||||
table is the name of your system, the three columns contain the name of
|
||||
the communication partner, the inputs, and the outputs.
|
||||
|
||||
**\<Diagram or Table>**
|
||||
|
||||
**\<optionally: Explanation of external domain interfaces>**
|
||||
|
||||
## Technical Context {#_technical_context}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
Technical interfaces (channels and transmission media) linking your
|
||||
system to its environment. In addition a mapping of domain specific
|
||||
input/output to the channels, i.e. an explanation which I/O uses which
|
||||
channel.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
Many stakeholders make architectural decision based on the technical
|
||||
interfaces between the system and its context. Especially infrastructure
|
||||
or hardware designers decide these technical interfaces.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
E.g. UML deployment diagram describing channels to neighboring systems,
|
||||
together with a mapping table showing the relationships between channels
|
||||
and input/output.
|
||||
|
||||
**\<Diagram or Table>**
|
||||
|
||||
**\<optionally: Explanation of technical interfaces>**
|
||||
|
||||
**\<Mapping Input/Output to Channels>**
|
||||
|
||||
# Solution Strategy {#section-solution-strategy}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
A short summary and explanation of the fundamental decisions and
|
||||
solution strategies, that shape system architecture. It includes
|
||||
|
||||
- technology decisions
|
||||
|
||||
- decisions about the top-level decomposition of the system, e.g.
|
||||
usage of an architectural pattern or design pattern
|
||||
|
||||
- decisions on how to achieve key quality goals
|
||||
|
||||
- relevant organizational decisions, e.g. selecting a development
|
||||
process or delegating certain tasks to third parties.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
These decisions form the cornerstones for your architecture. They are
|
||||
the foundation for many other detailed decisions or implementation
|
||||
rules.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
Keep the explanations of such key decisions short.
|
||||
|
||||
Motivate what was decided and why it was decided that way, based upon
|
||||
problem statement, quality goals and key constraints. Refer to details
|
||||
in the following sections.
|
||||
|
||||
See [Solution Strategy](https://docs.arc42.org/section-4/) in the arc42
|
||||
documentation.
|
||||
|
||||
# Building Block View {#section-building-block-view}
|
||||
|
||||
::: formalpara-title
|
||||
**Content**
|
||||
:::
|
||||
|
||||
The building block view shows the static decomposition of the system
|
||||
into building blocks (modules, components, subsystems, classes,
|
||||
interfaces, packages, libraries, frameworks, layers, partitions, tiers,
|
||||
functions, macros, operations, data structures, ...) as well as their
|
||||
dependencies (relationships, associations, ...)
|
||||
|
||||
This view is mandatory for every architecture documentation. In analogy
|
||||
to a house this is the *floor plan*.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
Maintain an overview of your source code by making its structure
|
||||
understandable through abstraction.
|
||||
|
||||
This allows you to communicate with your stakeholder on an abstract
|
||||
level without disclosing implementation details.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
The building block view is a hierarchical collection of black boxes and
|
||||
white boxes (see figure below) and their descriptions.
|
||||
|
||||
|
||||
|
||||
**Level 1** is the white box description of the overall system together
|
||||
with black box descriptions of all contained building blocks.
|
||||
|
||||
**Level 2** zooms into some building blocks of level 1. Thus it contains
|
||||
the white box description of selected building blocks of level 1,
|
||||
together with black box descriptions of their internal building blocks.
|
||||
|
||||
**Level 3** zooms into selected building blocks of level 2, and so on.
|
||||
|
||||
See [Building Block View](https://docs.arc42.org/section-5/) in the
|
||||
arc42 documentation.
|
||||
|
||||
## Whitebox Overall System {#_whitebox_overall_system}
|
||||
|
||||
Here you describe the decomposition of the overall system using the
|
||||
following white box template. It contains
|
||||
|
||||
- an overview diagram
|
||||
|
||||
- a motivation for the decomposition
|
||||
|
||||
- black box descriptions of the contained building blocks. For these
|
||||
we offer you alternatives:
|
||||
|
||||
- use *one* table for a short and pragmatic overview of all
|
||||
contained building blocks and their interfaces
|
||||
|
||||
- use a list of black box descriptions of the building blocks
|
||||
according to the black box template (see below). Depending on
|
||||
your choice of tool this list could be sub-chapters (in text
|
||||
files), sub-pages (in a Wiki) or nested elements (in a modeling
|
||||
tool).
|
||||
|
||||
- (optional:) important interfaces, that are not explained in the
|
||||
black box templates of a building block, but are very important for
|
||||
understanding the white box. Since there are so many ways to specify
|
||||
interfaces why do not provide a specific template for them. In the
|
||||
worst case you have to specify and describe syntax, semantics,
|
||||
protocols, error handling, restrictions, versions, qualities,
|
||||
necessary compatibilities and many things more. In the best case you
|
||||
will get away with examples or simple signatures.
|
||||
|
||||
***\<Overview Diagram>***
|
||||
|
||||
Motivation
|
||||
|
||||
: *\<text explanation>*
|
||||
|
||||
Contained Building Blocks
|
||||
|
||||
: *\<Description of contained building block (black boxes)>*
|
||||
|
||||
Important Interfaces
|
||||
|
||||
: *\<Description of important interfaces>*
|
||||
|
||||
Insert your explanations of black boxes from level 1:
|
||||
|
||||
If you use tabular form you will only describe your black boxes with
|
||||
name and responsibility according to the following schema:
|
||||
|
||||
+-----------------------+-----------------------------------------------+
|
||||
| **Name** | **Responsibility** |
|
||||
+=======================+===============================================+
|
||||
| *\<black box 1>* | *\<Text>* |
|
||||
+-----------------------+-----------------------------------------------+
|
||||
| *\<black box 2>* | *\<Text>* |
|
||||
+-----------------------+-----------------------------------------------+
|
||||
|
||||
If you use a list of black box descriptions then you fill in a separate
|
||||
black box template for every important building block . Its headline is
|
||||
the name of the black box.
|
||||
|
||||
### \<Name black box 1> {#__name_black_box_1}
|
||||
|
||||
Here you describe \<black box 1> according the the following black box
|
||||
template:
|
||||
|
||||
- Purpose/Responsibility
|
||||
|
||||
- Interface(s), when they are not extracted as separate paragraphs.
|
||||
This interfaces may include qualities and performance
|
||||
characteristics.
|
||||
|
||||
- (Optional) Quality-/Performance characteristics of the black box,
|
||||
e.g.availability, run time behavior, ....
|
||||
|
||||
- (Optional) directory/file location
|
||||
|
||||
- (Optional) Fulfilled requirements (if you need traceability to
|
||||
requirements).
|
||||
|
||||
- (Optional) Open issues/problems/risks
|
||||
|
||||
*\<Purpose/Responsibility>*
|
||||
|
||||
*\<Interface(s)>*
|
||||
|
||||
*\<(Optional) Quality/Performance Characteristics>*
|
||||
|
||||
*\<(Optional) Directory/File Location>*
|
||||
|
||||
*\<(Optional) Fulfilled Requirements>*
|
||||
|
||||
*\<(optional) Open Issues/Problems/Risks>*
|
||||
|
||||
### \<Name black box 2> {#__name_black_box_2}
|
||||
|
||||
*\<black box template>*
|
||||
|
||||
### \<Name black box n> {#__name_black_box_n}
|
||||
|
||||
*\<black box template>*
|
||||
|
||||
### \<Name interface 1> {#__name_interface_1}
|
||||
|
||||
...
|
||||
|
||||
### \<Name interface m> {#__name_interface_m}
|
||||
|
||||
## Level 2 {#_level_2}
|
||||
|
||||
Here you can specify the inner structure of (some) building blocks from
|
||||
level 1 as white boxes.
|
||||
|
||||
You have to decide which building blocks of your system are important
|
||||
enough to justify such a detailed description. Please prefer relevance
|
||||
over completeness. Specify important, surprising, risky, complex or
|
||||
volatile building blocks. Leave out normal, simple, boring or
|
||||
standardized parts of your system
|
||||
|
||||
### White Box *\<building block 1>* {#_white_box_emphasis_building_block_1_emphasis}
|
||||
|
||||
...describes the internal structure of *building block 1*.
|
||||
|
||||
*\<white box template>*
|
||||
|
||||
### White Box *\<building block 2>* {#_white_box_emphasis_building_block_2_emphasis}
|
||||
|
||||
*\<white box template>*
|
||||
|
||||
...
|
||||
|
||||
### White Box *\<building block m>* {#_white_box_emphasis_building_block_m_emphasis}
|
||||
|
||||
*\<white box template>*
|
||||
|
||||
## Level 3 {#_level_3}
|
||||
|
||||
Here you can specify the inner structure of (some) building blocks from
|
||||
level 2 as white boxes.
|
||||
|
||||
When you need more detailed levels of your architecture please copy this
|
||||
part of arc42 for additional levels.
|
||||
|
||||
### White Box \<\_building block x.1\_\> {#_white_box_building_block_x_1}
|
||||
|
||||
Specifies the internal structure of *building block x.1*.
|
||||
|
||||
*\<white box template>*
|
||||
|
||||
### White Box \<\_building block x.2\_\> {#_white_box_building_block_x_2}
|
||||
|
||||
*\<white box template>*
|
||||
|
||||
### White Box \<\_building block y.1\_\> {#_white_box_building_block_y_1}
|
||||
|
||||
*\<white box template>*
|
||||
|
||||
# Runtime View {#section-runtime-view}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
The runtime view describes concrete behavior and interactions of the
|
||||
system's building blocks in form of scenarios from the following areas:
|
||||
|
||||
- important use cases or features: how do building blocks execute
|
||||
them?
|
||||
|
||||
- interactions at critical external interfaces: how do building blocks
|
||||
cooperate with users and neighboring systems?
|
||||
|
||||
- operation and administration: launch, start-up, stop
|
||||
|
||||
- error and exception scenarios
|
||||
|
||||
Remark: The main criterion for the choice of possible scenarios
|
||||
(sequences, workflows) is their **architectural relevance**. It is
|
||||
**not** important to describe a large number of scenarios. You should
|
||||
rather document a representative selection.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
You should understand how (instances of) building blocks of your system
|
||||
perform their job and communicate at runtime. You will mainly capture
|
||||
scenarios in your documentation to communicate your architecture to
|
||||
stakeholders that are less willing or able to read and understand the
|
||||
static models (building block view, deployment view).
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
There are many notations for describing scenarios, e.g.
|
||||
|
||||
- numbered list of steps (in natural language)
|
||||
|
||||
- activity diagrams or flow charts
|
||||
|
||||
- sequence diagrams
|
||||
|
||||
- BPMN or EPCs (event process chains)
|
||||
|
||||
- state machines
|
||||
|
||||
- ...
|
||||
|
||||
See [Runtime View](https://docs.arc42.org/section-6/) in the arc42
|
||||
documentation.
|
||||
|
||||
## \<Runtime Scenario 1> {#__runtime_scenario_1}
|
||||
|
||||
- *\<insert runtime diagram or textual description of the scenario>*
|
||||
|
||||
- *\<insert description of the notable aspects of the interactions
|
||||
between the building block instances depicted in this diagram.\>*
|
||||
|
||||
## \<Runtime Scenario 2> {#__runtime_scenario_2}
|
||||
|
||||
## ... {#_}
|
||||
|
||||
## \<Runtime Scenario n> {#__runtime_scenario_n}
|
||||
|
||||
# Deployment View {#section-deployment-view}
|
||||
|
||||
::: formalpara-title
|
||||
**Content**
|
||||
:::
|
||||
|
||||
The deployment view describes:
|
||||
|
||||
1. technical infrastructure used to execute your system, with
|
||||
infrastructure elements like geographical locations, environments,
|
||||
computers, processors, channels and net topologies as well as other
|
||||
infrastructure elements and
|
||||
|
||||
2. mapping of (software) building blocks to that infrastructure
|
||||
elements.
|
||||
|
||||
Often systems are executed in different environments, e.g. development
|
||||
environment, test environment, production environment. In such cases you
|
||||
should document all relevant environments.
|
||||
|
||||
Especially document a deployment view if your software is executed as
|
||||
distributed system with more than one computer, processor, server or
|
||||
container or when you design and construct your own hardware processors
|
||||
and chips.
|
||||
|
||||
From a software perspective it is sufficient to capture only those
|
||||
elements of an infrastructure that are needed to show a deployment of
|
||||
your building blocks. Hardware architects can go beyond that and
|
||||
describe an infrastructure to any level of detail they need to capture.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
Software does not run without hardware. This underlying infrastructure
|
||||
can and will influence a system and/or some cross-cutting concepts.
|
||||
Therefore, there is a need to know the infrastructure.
|
||||
|
||||
Maybe a highest level deployment diagram is already contained in section
|
||||
3.2. as technical context with your own infrastructure as ONE black box.
|
||||
In this section one can zoom into this black box using additional
|
||||
deployment diagrams:
|
||||
|
||||
- UML offers deployment diagrams to express that view. Use it,
|
||||
probably with nested diagrams, when your infrastructure is more
|
||||
complex.
|
||||
|
||||
- When your (hardware) stakeholders prefer other kinds of diagrams
|
||||
rather than a deployment diagram, let them use any kind that is able
|
||||
to show nodes and channels of the infrastructure.
|
||||
|
||||
See [Deployment View](https://docs.arc42.org/section-7/) in the arc42
|
||||
documentation.
|
||||
|
||||
## Infrastructure Level 1 {#_infrastructure_level_1}
|
||||
|
||||
Describe (usually in a combination of diagrams, tables, and text):
|
||||
|
||||
- distribution of a system to multiple locations, environments,
|
||||
computers, processors, .., as well as physical connections between
|
||||
them
|
||||
|
||||
- important justifications or motivations for this deployment
|
||||
structure
|
||||
|
||||
- quality and/or performance features of this infrastructure
|
||||
|
||||
- mapping of software artifacts to elements of this infrastructure
|
||||
|
||||
For multiple environments or alternative deployments please copy and
|
||||
adapt this section of arc42 for all relevant environments.
|
||||
|
||||
***\<Overview Diagram>***
|
||||
|
||||
Motivation
|
||||
|
||||
: *\<explanation in text form>*
|
||||
|
||||
Quality and/or Performance Features
|
||||
|
||||
: *\<explanation in text form>*
|
||||
|
||||
Mapping of Building Blocks to Infrastructure
|
||||
|
||||
: *\<description of the mapping>*
|
||||
|
||||
## Infrastructure Level 2 {#_infrastructure_level_2}
|
||||
|
||||
Here you can include the internal structure of (some) infrastructure
|
||||
elements from level 1.
|
||||
|
||||
Please copy the structure from level 1 for each selected element.
|
||||
|
||||
### *\<Infrastructure Element 1>* {#__emphasis_infrastructure_element_1_emphasis}
|
||||
|
||||
*\<diagram + explanation>*
|
||||
|
||||
### *\<Infrastructure Element 2>* {#__emphasis_infrastructure_element_2_emphasis}
|
||||
|
||||
*\<diagram + explanation>*
|
||||
|
||||
...
|
||||
|
||||
### *\<Infrastructure Element n>* {#__emphasis_infrastructure_element_n_emphasis}
|
||||
|
||||
*\<diagram + explanation>*
|
||||
|
||||
# Cross-cutting Concepts {#section-concepts}
|
||||
|
||||
::: formalpara-title
|
||||
**Content**
|
||||
:::
|
||||
|
||||
This section describes overall, principal regulations and solution ideas
|
||||
that are relevant in multiple parts (= cross-cutting) of your system.
|
||||
Such concepts are often related to multiple building blocks. They can
|
||||
include many different topics, such as
|
||||
|
||||
- models, especially domain models
|
||||
|
||||
- architecture or design patterns
|
||||
|
||||
- rules for using specific technology
|
||||
|
||||
- principal, often technical decisions of an overarching (=
|
||||
cross-cutting) nature
|
||||
|
||||
- implementation rules
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
Concepts form the basis for *conceptual integrity* (consistency,
|
||||
homogeneity) of the architecture. Thus, they are an important
|
||||
contribution to achieve inner qualities of your system.
|
||||
|
||||
Some of these concepts cannot be assigned to individual building blocks,
|
||||
e.g. security or safety.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
The form can be varied:
|
||||
|
||||
- concept papers with any kind of structure
|
||||
|
||||
- cross-cutting model excerpts or scenarios using notations of the
|
||||
architecture views
|
||||
|
||||
- sample implementations, especially for technical concepts
|
||||
|
||||
- reference to typical usage of standard frameworks (e.g. using
|
||||
Hibernate for object/relational mapping)
|
||||
|
||||
::: formalpara-title
|
||||
**Structure**
|
||||
:::
|
||||
|
||||
A potential (but not mandatory) structure for this section could be:
|
||||
|
||||
- Domain concepts
|
||||
|
||||
- User Experience concepts (UX)
|
||||
|
||||
- Safety and security concepts
|
||||
|
||||
- Architecture and design patterns
|
||||
|
||||
- \"Under-the-hood\"
|
||||
|
||||
- development concepts
|
||||
|
||||
- operational concepts
|
||||
|
||||
Note: it might be difficult to assign individual concepts to one
|
||||
specific topic on this list.
|
||||
|
||||
|
||||
|
||||
See [Concepts](https://docs.arc42.org/section-8/) in the arc42
|
||||
documentation.
|
||||
|
||||
## *\<Concept 1>* {#__emphasis_concept_1_emphasis}
|
||||
|
||||
*\<explanation>*
|
||||
|
||||
## *\<Concept 2>* {#__emphasis_concept_2_emphasis}
|
||||
|
||||
*\<explanation>*
|
||||
|
||||
...
|
||||
|
||||
## *\<Concept n>* {#__emphasis_concept_n_emphasis}
|
||||
|
||||
*\<explanation>*
|
||||
|
||||
# Architecture Decisions {#section-design-decisions}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
Important, expensive, large scale or risky architecture decisions
|
||||
including rationales. With \"decisions\" we mean selecting one
|
||||
alternative based on given criteria.
|
||||
|
||||
Please use your judgement to decide whether an architectural decision
|
||||
should be documented here in this central section or whether you better
|
||||
document it locally (e.g. within the white box template of one building
|
||||
block).
|
||||
|
||||
Avoid redundancy. Refer to section 4, where you already captured the
|
||||
most important decisions of your architecture.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
Stakeholders of your system should be able to comprehend and retrace
|
||||
your decisions.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
Various options:
|
||||
|
||||
- ADR ([Documenting Architecture
|
||||
Decisions](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions))
|
||||
for every important decision
|
||||
|
||||
- List or table, ordered by importance and consequences or:
|
||||
|
||||
- more detailed in form of separate sections per decision
|
||||
|
||||
See [Architecture Decisions](https://docs.arc42.org/section-9/) in the
|
||||
arc42 documentation. There you will find links and examples about ADR.
|
||||
|
||||
# Quality Requirements {#section-quality-scenarios}
|
||||
|
||||
::: formalpara-title
|
||||
**Content**
|
||||
:::
|
||||
|
||||
This section contains all quality requirements as quality tree with
|
||||
scenarios. The most important ones have already been described in
|
||||
section 1.2. (quality goals)
|
||||
|
||||
Here you can also capture quality requirements with lesser priority,
|
||||
which will not create high risks when they are not fully achieved.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
Since quality requirements will have a lot of influence on architectural
|
||||
decisions you should know for every stakeholder what is really important
|
||||
to them, concrete and measurable.
|
||||
|
||||
See [Quality Requirements](https://docs.arc42.org/section-10/) in the
|
||||
arc42 documentation.
|
||||
|
||||
## Quality Tree {#_quality_tree}
|
||||
|
||||
::: formalpara-title
|
||||
**Content**
|
||||
:::
|
||||
|
||||
The quality tree (as defined in ATAM -- Architecture Tradeoff Analysis
|
||||
Method) with quality/evaluation scenarios as leafs.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
The tree structure with priorities provides an overview for a sometimes
|
||||
large number of quality requirements.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
The quality tree is a high-level overview of the quality goals and
|
||||
requirements:
|
||||
|
||||
- tree-like refinement of the term \"quality\". Use \"quality\" or
|
||||
\"usefulness\" as a root
|
||||
|
||||
- a mind map with quality categories as main branches
|
||||
|
||||
In any case the tree should include links to the scenarios of the
|
||||
following section.
|
||||
|
||||
## Quality Scenarios {#_quality_scenarios}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
Concretization of (sometimes vague or implicit) quality requirements
|
||||
using (quality) scenarios.
|
||||
|
||||
These scenarios describe what should happen when a stimulus arrives at
|
||||
the system.
|
||||
|
||||
For architects, two kinds of scenarios are important:
|
||||
|
||||
- Usage scenarios (also called application scenarios or use case
|
||||
scenarios) describe the system's runtime reaction to a certain
|
||||
stimulus. This also includes scenarios that describe the system's
|
||||
efficiency or performance. Example: The system reacts to a user's
|
||||
request within one second.
|
||||
|
||||
- Change scenarios describe a modification of the system or of its
|
||||
immediate environment. Example: Additional functionality is
|
||||
implemented or requirements for a quality attribute change.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
Scenarios make quality requirements concrete and allow to more easily
|
||||
measure or decide whether they are fulfilled.
|
||||
|
||||
Especially when you want to assess your architecture using methods like
|
||||
ATAM you need to describe your quality goals (from section 1.2) more
|
||||
precisely down to a level of scenarios that can be discussed and
|
||||
evaluated.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
Tabular or free form text.
|
||||
|
||||
# Risks and Technical Debts {#section-technical-risks}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
A list of identified technical risks or technical debts, ordered by
|
||||
priority
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
"Risk management is project management for grown-ups" (Tim Lister,
|
||||
Atlantic Systems Guild.)
|
||||
|
||||
This should be your motto for systematic detection and evaluation of
|
||||
risks and technical debts in the architecture, which will be needed by
|
||||
management stakeholders (e.g. project managers, product owners) as part
|
||||
of the overall risk analysis and measurement planning.
|
||||
|
||||
::: formalpara-title
|
||||
**Form**
|
||||
:::
|
||||
|
||||
List of risks and/or technical debts, probably including suggested
|
||||
measures to minimize, mitigate or avoid risks or reduce technical debts.
|
||||
|
||||
See [Risks and Technical Debt](https://docs.arc42.org/section-11/) in
|
||||
the arc42 documentation.
|
||||
|
||||
# Glossary {#section-glossary}
|
||||
|
||||
::: formalpara-title
|
||||
**Contents**
|
||||
:::
|
||||
|
||||
The most important domain and technical terms that your stakeholders use
|
||||
when discussing the system.
|
||||
|
||||
You can also see the glossary as source for translations if you work in
|
||||
multi-language teams.
|
||||
|
||||
::: formalpara-title
|
||||
**Motivation**
|
||||
:::
|
||||
|
||||
You should clearly define your terms, so that all stakeholders
|
||||
|
||||
- have an identical understanding of these terms
|
||||
|
||||
- do not use synonyms and homonyms
|
||||
|
||||
A table with columns \<Term> and \<Definition>.
|
||||
|
||||
Potentially more columns in case you need translations.
|
||||
|
||||
See [Glossary](https://docs.arc42.org/section-12/) in the arc42
|
||||
documentation.
|
||||
|
||||
+-----------------------+-----------------------------------------------+
|
||||
| Term | Definition |
|
||||
+=======================+===============================================+
|
||||
| *\<Term-1>* | *\<definition-1>* |
|
||||
+-----------------------+-----------------------------------------------+
|
||||
| *\<Term-2>* | *\<definition-2>* |
|
||||
+-----------------------+-----------------------------------------------+
|
||||
BIN
Binary file not shown.
|
After Width: | Height: | Size: 81 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 275 KiB |
BIN
Binary file not shown.
|
After Width: | Height: | Size: 35 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 8.0 KiB |
@@ -0,0 +1,5 @@
|
||||
https://seths.blog/2019/11/busy-is-a-choice-productive-is-a-skill/
|
||||
|
||||
Productivity, on the other hand, has little to do with busy.
|
||||
Productivity requires bringing soft skills (real skills) to the table in service of the generous work you seek to do.
|
||||
Productivity is learned. And productivity takes guts.
|
||||
+16
@@ -0,0 +1,16 @@
|
||||
http://dantawfik.com/craftsmanship-the-alternative-to-the-four-hour-work-week-mindset-1
|
||||
|
||||
What is missed in all of this is the mindset of craftsmanship; that one’s expertise and deliberate focus on one’s craft is actually the primary driver for success and not some crapshoot of a series of hacks.
|
||||
|
||||
What happens on the periphery — whether it be the towel slapping we see on Twitter from tech celebrities or headline gossip out of TechCrunch — is not actually meaningful as a foundation of a business or a profession. Neither are the number of coffee meetings you have scheduled or the amount of networking meetings you attend. These things are tertiary at best, and at worst, just plain old distractions.
|
||||
|
||||
To be successful over the course of a career requires the application and accumulation of expertise. This assumes that for any given undertaking you either provide expertise or you are just a bystander. It’s the experts that are the drivers—an expertise that is gained from a curiosity, and a mindset of treating one’s craft very seriously.
|
||||
|
||||
You have to take an interest in these domains because there is no one else to fill these roles in your early stage company
|
||||
|
||||
You’re not simply working on the idea in front of you, you’re building the knowledge to succeed at your next projects as well.
|
||||
|
||||
Startup graveyards are full of visionaries without expertise or the proper skills to execute, for no other reason than ideas are not self executing, but are rather made into being by intense engagement by skilled operators.
|
||||
|
||||
If you are to optimize for anything, optimize for the long term. Use the challenges of your business today to build mastery in your craft. There is no guarantee that any one venture will succeed, but that mastery will bend luck in your favor over the long course of your career.
|
||||
|
||||
@@ -0,0 +1,52 @@
|
||||
Tags: [[Article]] [[Productivity]] - [[Scheduling]] [[Time Blocking]]
|
||||
Author: [[Charlie Gilkey]]
|
||||
From: https://www.productiveflourishing.com/time-blocking/
|
||||
|
||||
## Highlights:
|
||||
|
||||
Rather than thinking about time in an open, unstructured way, I approach time blocking by figuring out a coherent daily structure with four different kinds of blocks based upon the type of activity done in those blocks.
|
||||
|
||||
Focus blocks are 90–120 minute blocks of time where you’re especially creative, inspired, and able to do high-level work that requires focus. Admin blocks are 30–60 minute lower-energy blocks of time where you’re not in the zone to do the work that requires heavy lifting, but there are still other types of work you can do effectively. Social blocks are 90–120 minute blocks of time where you’re primed and energetically in the right space to meet with other people. Recovery blocks are variable-length blocks of time that you use for exercise, meditation, and self-care.
|
||||
|
||||
most people have a hard time creating and using more than three per day because of distractions, interruptions, daily routines, and a lack of intention
|
||||
|
||||
Focus blocks fuel your highest-value deep work. No focus blocks, no finished deep work. It’s really that simple
|
||||
|
||||
rather than thinking in terms of hours required to get something done, you can just count the focus blocks you have available. Anything over ten hours starts to become hard for us to deal with because it gets amorphous and hard to visualize, but five blocks is easier to understand because we can think about the chunks of the projects we can do in that amount of time.
|
||||
|
||||
it’s the same amount of energy in a different configuration, but the configuration makes all the difference
|
||||
|
||||
You may also need to use focus blocks for projects and work that look like admin but actually require a good bit of strategizing, thinking, problem-solving, or wordsmithing to get right
|
||||
|
||||
Pushing too many focus blocks leads to creative burnout. It’s quite common for people to have a four- or five-block day, only to drag for the next few days and wonder what’s wrong.
|
||||
|
||||
Consistent progress is better than fits and starts.
|
||||
|
||||
The number of focus blocks you have available is the limiting factor to how quickly and steadily you’ll be able to make progress on your high-value creative projects
|
||||
|
||||
anything that supports the deep work but isn’t the deep work itself
|
||||
|
||||
Admin blocks give you time to reflect upon your work, and they create space and context for things to gel. Knowing that there will be admin blocks allows you to stress less about all the admin work that does need to be attended to. There’s a time and a space for everything. Well-positioned admin blocks make it easier to catch the frogs because that task is confined to smaller periods of the day.
|
||||
|
||||
Focus blocks are focused on creating something, whereas social blocks are focused on connecting with someone.
|
||||
|
||||
Productivity is about more than getting stuff done — it’s about using your resources in ways that bring about the most value in your life.
|
||||
|
||||
I usually will speak of social blocks as social/service blocks to remind people that real-time service hours are social blocks.
|
||||
|
||||
|
||||
they make for great bookends to other blocks because most of us honor commitments to other people more than we honor commitments to ourselves
|
||||
|
||||
Focus, admin, and social blocks are energy output blocks,
|
||||
|
||||
we actually need to be more intentional about them than about any of the other blocks precisely because we’re over-focused on output.
|
||||
|
||||
What’s more important than the type of activity is what the activity does for you. A major upshot to acknowledging and using recovery blocks is that it allows you to find dead zones in your day that can be repurposed for recovery
|
||||
|
||||
As a general rule, plan on a recovery block for every two focus or social blocks.
|
||||
|
||||
recovery blocks can also be a good follow-on to a focus block since focus blocks are often the most taxing of the blocks.
|
||||
|
||||
Don’t go longer than two Focus and/or Social blocks back to back without a Recovery block. You need to recharge, and the work and the people you’re meeting with will benefit more. Put your Focus blocks where you have the best creative energy. If you’ve filled out the Productivity Heatmap, red and orange times are where your Focus Blocks should go. Put your Social blocks where you’re most fit for human consumption. Note that you can be red/orange in the morning for solo work but not for meeting with folks. Avoid putting an Admin Block first thing in the morning, but if you must, be intentional about processing it, looking only for items that are relevant for the day. Recovery Blocks are the wildcard — I highly suggest a morning routine that includes some combination of movement, eating, meditation/prayer, and planning/intention-setting. Night owls still benefit by starting with self-care. As best you can, be consistent with the times you’re putting your blocks in. For instance, if your best creative time is from 9 a.m.–12 p.m., try to have two creative blocks per morning every workday. If you’re most fit for human consumption in the afternoon, try to schedule your meetings for the afternoon. This will help you get into good grooves, improve your habit-building, and give you some powerful defaults that limit decision-fatigue. Chores and commutes are closest to Admin blocks, so you can give them time as such. That said, feel free to create Commute or Chores blocks if that makes the most sense for you.
|
||||
|
||||
In general, people struggle the most with finding/creating Focus blocks, with the real root cause being that it’s harder to claim time for ourselves than to give it to others.
|
||||
@@ -0,0 +1,5 @@
|
||||
### Notes
|
||||
```dataview
|
||||
table file.ctime as Date from "300-resources/Productivity"
|
||||
sort file.name
|
||||
```
|
||||
+31
@@ -0,0 +1,31 @@
|
||||
https://blog.rescuetime.com/smart-goals-examples/
|
||||
|
||||
|
||||
SMART goals framework dictates that your goals should be:
|
||||
- ==Specific: You know exactly what needs to get done. There’s no ambiguity or vagueness in how and when your goal will happen==
|
||||
- ==Measurable: You have a meaningful and motivating way to track progress and measure your results. You’ll know if you’ve hit your goal 80%, 100% or missed the mark entirely.==
|
||||
- ==Achievable: You’re not shooting for the moon (unless you think you can realistically hit i==
|
||||
- ==Relevant: You’re working towards something that is worthwhile, timely, and deeply connected to your own skills and long-term goals. You’ll be motivated to work towards this goal.==
|
||||
- ==Time-bound: There are clear start and end dates you’re working towards. (It’s important to note that SMART goals are most useful for more short-term goals—one month to one year).==
|
||||
|
||||
On the surface, SMART goals are great at ensuring you don’t fall into bad goal-setting red flags. For example: Hastily choosing a number or metric to go after without thinking it through. For example, saying you want to increase sales by 40% without having a reason why that’s the metric and goal to go after. Glossing over how other teams will be involved. For example, saying that you’ll build a new feature without involving your product team. Missing a crucial step along the way. For example, agreeing on a clear first step and final result but not knowing how you’re going to get from A to B.
|
||||
|
||||
1. Replace “should” with “will” In her book The Crossroads of Should and Must, artist Elle Luna describes the word should as a non-commitment. “Should” is a non-starter for your goals. Instead, be specific and use action words like “will”. For example, “By the end of the week, I should will finish and send the final website design to my client.”
|
||||
|
||||
2. Change “soon” to a specific timeline Despite time-bound being a large part of the SMART goal system, many people are afraid to commit to an actual specific date. But your goals lose power if they don’t have an end date. For example, “I will send 10 cold emails to prospective clients soon by 4pm on Wednesday.”
|
||||
|
||||
3. Switch “need to” to “want to” Saying you “need” to do something frames your goal in a negative way. Instead, saying you “want” to do it is a much more positive way to stay motivated. (This is mostly when talking about personal goals. In the workplace, there are many situations where you “need” to do something). For example, “I need to want to wake up at 6:30 am each morning so that I can go to the gym before work.”
|
||||
|
||||
4. Replace “quit” with “stop” While your goal might be to change a behavior, saying you want to “quit” has all sorts of negative connotations that can get in your way. No one wants to feel like a quitter (even if they want to quit something). Instead, say you’ll “stop” doing it. For example, “For the next 3 weeks, I will quit stop eating lunch at my desk and take a proper break.”
|
||||
|
||||
5. Change “Never” to a specific action Few things turn us off from doing a task like feeling overwhelmed and pressured. When you say you’ll “never” do something again, you’re putting an inordinate amount of pressure on yourself and will be more likely to give up or procrastinate. Instead, set in place a replacement action for the thing you want to “never” do again. For example, “I will never be late add a 15-minute buffer in between my meeting slots each day so I won’t be late for the Monday morning stand up meeting again.”
|
||||
|
||||
1. Spending more time on meaningful work
|
||||
|
||||
SMART goal: “Every day this week, I will work on our new marketing site redesign from 8:30 – 10:30 am without interruption.” Why this works: Not only does this goal set a clear timeline and expectations, it does so in a positive way that is realistic and easy to stay motivated towards. Each day, you know what you’re doing, when you’re going to do it, and why it matters.
|
||||
|
||||
SMART goal: “I will schedule 2 hours on Thursday afternoon to personally email 10 people I’m already connected with on LinkedIn and ask them if they have 15 minutes to talk about their career path and how I should move forward.” Why this works: This SMART goal answers all of the key questions—what you’re going to do, when, the process you’re going to use, and what you expect out of it. Additionally, it does so in a positive and motivating way, turning a big, audacious goal into something manageable.
|
||||
|
||||
SMART goal: “Every Monday, Wednesday, and Friday from 6:30–8:30 pm, I will work towards the Responsive Web Design certificate course on freeCodeCamp.” Why this works: This SMART goal leaves nothing unclear. You know the skill you want to learn, how you’re going to learn it, and when and where that will happen.
|
||||
|
||||
SMART goal: “I will set a RescueTime Alert to notify me when I’ve spent more than 20 minutes on work tasks outside of the workday to help build a habit of leaving work at work.” Why this works: Clarity is key. This SMART goal includes the specific process you’re going to take as well as the reasoning behind why you picked this goal in the first place.
|
||||
@@ -0,0 +1,5 @@
|
||||
### Notes
|
||||
```dataview
|
||||
table file.ctime as Date from "300-resources/Travel"
|
||||
sort file.name
|
||||
```
|
||||
@@ -0,0 +1,11 @@
|
||||
How do you create suspense? I'm asked that question often, and it seems that every writers' symposium has a class with that title. It's an important technical issue, and not just for so-called suspense novels. Every novel needs a narrative engine, a reason for people to keep reading to the end, whatever the subject, style, genre or approach. But it's a bad question. Its very form misleads writers and pushes them onto an unhelpful and overcomplicated track.
|
||||
|
||||
Because "How do you create suspense?" has the same interrogatory shape as "How do you bake a cake?" And we all know --- in theory or practice --- how to bake a cake. We need ingredients, and we infer that the better quality those ingredients are, the better quality the cake will be. We know that we have to mix and stir those ingredients, and we're led to believe that the more thoroughly and conscientiously we combine them, the better the cake will taste. We know we have to cook the cake in an oven, and we figure that the more exact the temperature and timing, the better the cake will look.
|
||||
|
||||
So writers are taught to focus on ingredients and their combination. They're told they should create attractive, sympathetic characters, so that readers will care about them deeply, and then to plunge those characters into situations of continuing peril, the descent into which is the mixing and stirring, and the duration and horrors of which are the timing and temperature.
|
||||
|
||||
But it's really much simpler than that. "How do you bake a cake?" has the wrong structure. It's too indirect. The right structure and the right question is: "How do you make your family hungry?"
|
||||
|
||||
And the answer is: You make them wait four hours for dinner.
|
||||
|
||||
As novelists, we should ask or imply a question at the beginning of the story, and then we should delay the answer. (Which is what I did here, and you're still reading, right?)
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user