-
Notifications
You must be signed in to change notification settings - Fork 0
/
search.xml
168 lines (168 loc) · 61.6 KB
/
search.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
<?xml version="1.0" encoding="utf-8"?>
<search>
<entry>
<title><![CDATA[CSS常用样式笔记]]></title>
<url>%2Fcategory%2F20200310-css-one.html</url>
<content type="text"><![CDATA[引言 本文是 CSS 学习过程中的笔记之一，主要记录了 Box 模型中常用的属性样式，以及一些容易忽视而又需要注意的情况。本文前后还有其它内容，待后续再做补充。 Box 模型常用的属性Box 模型常用的属性12345<div class="bg"> <div class="item"> Hello World! Hello World! Hello World! Hello World! Hello World! Hello World! Hello World! Hello World! Hello World! Hello World! Hello World! Hello World! Hello World! Hello World! </div></div> 123456789101112131415161718192021222324252627282930313233div.bg{ border:3px solid brown; background-color:bisque;/* 指定bg元素的大小 */ height:200px; width:300px;}/* Box 模型的边框和边距 */div.item{ background-color:lightgreen; margin:5px; margin-top:15px;/* 此处对比有无 solid 的区别 */ border:2px solid black; border-left:5px solid red; border-top:5px green;/* 对比 padding 与 margin 的区别 */ padding:5px; padding-bottom:1px;}/* Box 模型内容的溢出处理 */div.bg{/* overflow 参数可选：auto hidden scroll 分别对应 自动 隐藏 显示 *//* 注意对比 scroll 与 auto 在内容不多时的区别 */ overflow:auto; overflow-x:hidden; overflow-y:scroll;} Position 的几个参数Position 属性一般用于确定元素的位置 static：默认值，对 top bottom left right 属性不生效 relative：相对位置，挪出来的空间不会被其它元素填充 fixed：固定位置（含滚动状态），即相对 window 元素的位置 absolute：绝对位置，即相对除 static 以外的父元素的位置。如果元素的外一层元素为 static 属性元素，则会继续往外寻找，直到寻找到属性为「非 static」的元素或无更外层元素为止 sticky：附着位置，是测试中的属性，显示效果为 relative 与 fixed 的组合，在到达设定的位置边界前表现为 relative 即随页面滚动而滚动；在到达边界后表现为 fixed 即固定位置不随滚动而移动 1234567891011121314151617181920212223242526<div class="bg"> <div class="item1" id="item"> Hello World one<br> Hello World one<br> Hello World one<br> Hello World one<br> </div> <div class="item2" id="item"> Hello World two<br> Hello World two<br> Hello World two<br> Hello World two<br> </div> <div class="item3" id="item"> Hello World three<br> Hello World three<br> Hello World three<br> Hello World three<br> </div> <div class="item3" id="item"> Hello World four<br> Hello World four<br> Hello World four<br> Hello World four<br> </div></div> 1234567891011121314151617181920212223242526272829303132333435363738394041424344/* 用 id 来设置属性选择器 */#item{ border-bottom:2px solid grey; padding:3px; width:130px;}div.bg{ position:relative; top:50px; left:50px; border:3px solid brown; background-color:bisque; height:200px; width:300px; overflow:auto;}/* Box 模型的位置 */div.item1{ position:absolute; top:15px; left:15px;}div.item2{/* 注意拉动滚动条时，item2 的位置 */ position:fixed; top:76px; left:220px; color:DarkTurquoise;}div.item3{ position:relative; top:120px; left:15px;} 水平居中12345678<div class="bg"> <div class="item"> Hello World one<br> Hello World one<br> Hello World one<br> Hello World one<br> </div></div> 123456789101112131415161718192021div.bg{ border:3px solid brown; background-color:bisque; height:200px; width:300px;}/* 水平居中 */div.item{ margin-top:5px; width:250px; border:2px solid grey; /* div 内部文本水平居中 */ text-align:center;/* div 本身水平居中 */ margin-left:auto; margin-right:auto;} 块浮动123456789101112131415161718<ul class="feeds"> <li> <div class="avatar"> <img src="https://feng-bbs-att-1255531212.image.myqcloud.com/2018/11/29/094524m2okncfoeqkj1zv8.png?imageMogr2/thumbnail/64x/format/jpg/interlace/0/quality/100" alt="头像" > </div> <div class="content"> 十分感谢以上锋友为大家带来有关越狱的干货帖与精华帖，想了解更多相关精彩内容请点击进入各作者主页关注他！有任何问题也可在下方回复并@你想问的大佬，记得要关注才能@到对方喔！ </div> </li> <li> <div class="avatar"> <img src="https://feng-bbs-att-1255531212.image.myqcloud.com/2018/11/29/094524m2okncfoeqkj1zv8.png?imageMogr2/thumbnail/64x/format/jpg/interlace/0/quality/100" alt="头像" > </div> <div class="content"> 十分感谢以上锋友为大家带来有关越狱的干货帖与精华帖，想了解更多相关精彩内容请点击进入各作者主页关注他！有任何问题也可在下方回复并@你想问的大佬，记得要关注才能@到对方喔！ </div> </li></ul> 123456789101112131415161718192021222324252627282930313233343536373839ul.feeds{/* 去掉列表中每一项最左边的黑点和留白 */ padding:0px;}/* 设置列表项的属性 */ul.feeds > li{/* 此处注意 display 属性分别为 block 和 table 时的区别 */ display:table; margin-top:2px; position:relative; width:400px; border:2px solid red; padding:5px;/* 按行清除浮动 */ clear:both;}ul.feeds > li div.avatar img{/* 设置头像大小 */ width:50px}ul.feeds > li div.avatar{/* 设置头像左浮动 */ float:left; width:50px;}ul.feeds > li div.content{/* 设置文本右浮动 */ float:right; width:340px;} 后记 本文是学习 CSS 相关技术的笔记之一，主要记录 CSS 一些常用的样式及注意事项，仅供自己在后续使用时参考。]]></content>
<categories>
<category>笔记</category>
</categories>
<tags>
<tag>CSS</tag>
<tag>笔记</tag>
</tags>
</entry>
<entry>
<title><![CDATA[Bark 服务端部署及 https 配置]]></title>
<url>%2Fcategory%2F20190725-bark-two.html</url>
<content type="text"><![CDATA[引言 这篇文章 中简单介绍了 Bark 这个工具的使用方法，但从安全和隐私角度考虑，我们更希望能自己搭建服务端进行消息推送。本文将介绍如何自行部署 Bark 服务端，并启用 Https 安全通信协议。 部署 Bark 服务端并启动 部署 Bark 的服务端还是很简单的，参考 这个教程 中的”手动安装”即可。具体步骤可以参照下文，也可直接跳过本段，直接进入 Https 部署环节。 部署 Bark 服务端 首先在 这里 根据自己服务器的操作系统，下载对应的可执行文件。我的服务器操作系统是Ubuntu 18.04 x64版，所以下载的是 bark-server_linux_amd64 这个版本。 以 Linux 系统为例，通过 XFTP 等 ftp 工具将下载得到的 bark-server_linux_amd64 文件上传到要部署的服务器上，如 /home/ubuntu 中。接下来建议单独创建一个目录，用于存放服务端程序、数据库及日志文件，便于查看和管理。 1234567ubuntu@VM-0-8-ubuntu:~$ mkdir BarkSvrubuntu@VM-0-8-ubuntu:~$ mv bark-server_linux_amd64 ./BarkSvr/bark-serverubuntu@VM-0-8-ubuntu:~$ cd BarkSvrubuntu@VM-0-8-ubuntu:~/BarkSvr$ ls -ltotal 8628-rwxr-xr-- 1 ubuntu ubuntu 8834848 Jul 25 19:47 bark-server 启动 Bark 服务端并验证功能 上一步完成后，Bark 的服务端程序便存放好了。但是在 Linux 下需要先增加”执行”权限，然后启动程序开始监听网页请求。下文中的命令里，通过 -d . 参数指定了数据保存目录为当前目录，如果不加这个参数，则数据默认保存在 ./data/ 目录下。 123ubuntu@VM-0-8-ubuntu:~/BarkSvr$ chmod +x bark-serverubuntu@VM-0-8-ubuntu:~/BarkSvr$ ./bark-server -l 0.0.0.0 -p 8081 -d .INFO[2019-07-25 19:52:39] Serving HTTP on 0.0.0.0:8081 看到 INFO[2019-xx-xx xx:xx:xx] Serving HTTP on 0.0.0.0:8081 这行日志，说明服务端已经启动起来了。接下来可以用以下2个方法验证一下功能是否正常： 另外打开一个终端（Linux 或 macOS），并执行 curl http://{server}:{port}/ping 命令，其中 {server} 和 {port} 分别替换为部署了服务端的服务器 IP 地址和启动时配置的监听端口，本例中执行的命令如下（请自行替换你自己的服务器地址和监听端口）： 12ubuntu@VM-0-8-ubuntu:~$ curl 139.199.198.139:8081/ping{"code":200,"data":{"version":"1.0.0"},"message":"pong"} 打开前一篇文章中介绍的 这个工具 并切换到 GET 模式，按下图填写服务端地址（请自行替换你自己的服务器地址和监听端口）并发出请求： 以上两种方法均可以测试服务端的功能是否正常。如果收到 code 为200且 message 为”pong”的返回结果，说明服务端工作正常。如果是使用网页工具发送的测试请求，则通过网页的”Response Text”栏可以看到返回结果。 开启 Bark 服务端后台运行并绑定设备开启 Bark 服务端后台运行 上文直接运行的方式，会使得服务端运行在 Shell 前台，当终端断开连接时，程序就会被关闭。所以最好把服务端程序启动为后台程序，避免不小心关了终端导致服务中断。在终端中执行以下命令： 1234ubuntu@VM-0-8-ubuntu:~$ cd /home/ubuntu/BarkSvrubuntu@VM-0-8-ubuntu:~/BarkSvr$ nohup ./bark-server -l 0.0.0.0 -p 8081 -d ./data &[1] 18528ubuntu@VM-0-8-ubuntu:~/BarkSvr$ nohup: ignoring input and appending output to 'nohup.out' 此时服务端程序将会运行在后台，所有的程序日志都会写入到当前目录的 nohup.out 文件中，如果遇到问题，可以查看该文件获得运行日志分析问题。 绑定要推送的设备 打开 Bark 手机端，如果是第一次打开，参照 这篇文章 进行应用初始化。初始化完成后，点击右上角的”+”号，打开”添加私有服务器”界面，并按图中内容填写（自行替换你自己的服务器地址和监听端口），然后点击右上角的”✅”按钮确认。如果服务器地址或监听端口填写错误，确认时界面下方会有错误提示，请检查填写内容是否正确。 如果服务器地址和端口填写正确，程序将会自动返回到首页，并显示目前支持的几种推送格式，其中就包含本设备的设备识别码，如本机的识别码为 BAL9bUowzEqFNryvgPnEnS 。 接下来可以参考 这篇文章 测试推送服务，比如可以直接用浏览器访问 http://139.199.198.139:8081/BAL9bUowzEqFNryvgPnEnS/测试标题/测试推送文本 并在手机上查看是否收到相应推送。 配置 HTTPS 协议To be continued … 生成 SSL 证书配置 Apache 反向代理配置 Bark 客户端后记]]></content>
<categories>
<category>笔记</category>
</categories>
<tags>
<tag>笔记</tag>
<tag>Bark</tag>
</tags>
</entry>
<entry>
<title><![CDATA[Bark上手及脚本操作介绍]]></title>
<url>%2Fcategory%2F20190725-bark-one.html</url>
<content type="text"><![CDATA[引言 Bark 是一款我最近很常用的推送 App，具体介绍可以参考少数派的 这篇文章 以及小众软件的 这篇文章。简单来说，Bark 是一款超级轻量级的 iOS 端消息 push 接收工具，消息推送走的是苹果官方的 push 通道，实时性和稳定性都非常可靠。这个 App 支持自定义请求，自行部署服务器， 客户端 与 服务端 均是开源的，适合注重隐私的用户。 Bark上手及脚本操作介绍Bark上手 首先在 App Store 上下载 Bark 客户端，安装完成后打开安装的应用。第一次打开时，主界面如图，点击”注册设备”，并在弹出的授权窗口中，允许应用发送通知。 授权之后的应用主界面如图，显示了目前支持的几种推送消息格式的请求链接，它们均以 https://服务端地址/设备识别码/推送内容及参数 为格式。直接在浏览器中访问各个链接，可以测试 Bark 推送的各项功能，目前支持标题、正文、URL 跳转及自动复制功能。 Bark 请求参数说明 Bark 支持 GET 和 POST 请求，只需向服务端发起相应类型的请求，并传递相应的参数即可。请求的标准格式为 https://{server}/{key}/{category}/{title}/{message}?{option}={opt_val}&{option}={opt_val} ，各项参数的说明如下： server: 接收请求的服务端地址， 默认为 api.day.app，是 App 作者自有的服务器。用户自行部署服务端后可以将其替换掉； key：设备识别码，用于区分不同的设备，每次删除 Bark 应用再重新安装后会重置。发起请求时设备识别码决定了通知会被推送到哪部设备上，请保管好自己的设备识别码，避免被无聊人士骚扰； category: 保留字段，目前无用，后续作者可能会用于扩展功能，可以为空； title: 推送通知的标题，字号比正文粗，可以为空； message: 推送消息的正文，文本内容用”\n”换行； option: 其它参数，用于设置手机在接收到通知后的特殊操作，可以为空，目前支持以下三个参数： automaticallyCopy: 参数值为1时，收到通知推送后系统会自动复制通知文本。可通过 copy 参数配置复制的文本； copy: 配置自动/手动复制时，具体要复制的文本。没有该参数时默认复制通知文本全文； url: 配置点击通知时，要跳转的网页。没有该参数时点击通知自动打开 Bark 应用。 Bark 脚本操作方法GET 请求 GET 请求会将请求的各个参数直接放在链接中，Bark 应用的首页介绍的各个链接都是使用这种请求形式，可以直接使用浏览器访问来发起，如直接访问 https://api.day.app/yourkey/验证码是1234?automaticallyCopy=1 可以向 yourkey 对应的设备发送”验证码是1234”的通知，并让设备在收到通知后自动复制通知全文。 除了通过浏览器直接访问，还可以通过程序/脚本发起请求。以 Python 为例，通过 requests 库可以很简单地向服务端发起请求： 12345678910import requestsurl = "{server}/{key}/{title}/{msg}?automaticallyCopy=1"server_addr = "https://api.day.app" # 此处填写服务端地址my_key = "abcd1234dcba" # 此处填写自己的设备识别码my_title = "这是标题" # 此处填写通知标题my_msg = "验证码是1234" # 此处填写通知内容url = url.format(server=server_addr, key=my_key, title=my_title, msg=my_msg)r = requests.get(url) POST 请求 GET 请求会将参数明文暴露在访问的 URL 中，出于安全考虑，使用 POST 请求更为妥当。通过 POST 发起请求时，可以使用 这个工具 来发起。注意，通过 POST 发起请求时，应该向 {server}/{key}/ （如 https://api.day.app/abcd1234dcba/ ）而不是 {server} （如 https://api.day.app ）发起请求，设备识别码是请求地址的一部分。 设备收到的推送通知如图： 同样，我们可以通过程序/脚本发起请求。以 Python 为例，POST 请求的代码与 GET 请求的不太一样： 123456789101112131415161718import requestsurl = "{server}/{key}/"server_addr = "https://api.day.app" # 此处填写服务端地址my_key = "abcd1234dcba" # 此处填写自己的设备识别码my_title = "这是标题" # 此处填写通知标题my_msg = "验证码是1234" # 此处填写通知内容req_data = {}req_data["body"] = my_msgreq_data["title"] = my_title# req_data["automaticallyCopy"] = "1"# req_data["copy"] = "自动拷贝文本"# req_data["url"] = "https://cn.bing.com"# req_data["category"] = ""req_url = url.format(push_server, push_key)r = requests.post(url=req_url, data=req_data, headers={'Content-Type':'application/x-www-form-urlencoded;charset=utf-8'}) 后记 写这篇文章是因为现在网上很少 Bark 相关的内容，尤其是如何通过程序/脚本来发送通知的内容，根本找不到资料，只能自己摸索（大概是我太菜了吧……）。这篇文章算是个整理吧，接下来准备马克一下怎么部署自己的服务端，以及配置 Apache 实现 https 安全连接。Mew～]]></content>
<categories>
<category>笔记</category>
</categories>
<tags>
<tag>笔记</tag>
<tag>Bark</tag>
</tags>
</entry>
<entry>
<title><![CDATA[洛陽集：結辯的魔術 - 黃執中的日志]]></title>
<url>%2Fcategory%2F20190527-jonas-hwang-blog-04.html</url>
<content type="text"><![CDATA[學長，看過您博客很多的文章，但是感覺沒有一篇是針對四辯的。四辯感覺和其他辯位是完全不同的，一辯稿子已拿穩，二三辯需清晰思路，守住戰場，但是四辯總覺得無法完全臨場發揮，又不知該如何準備，死稿上場過於僵硬。剛開始學辯論半年，一直是四辯手，求百忙之間抽空一答！ 常常當結辯，卻很少談結辯——有時候，是因為近鄉情更怯。 更多時候，是因為在一場辯論中，結辯通常不是來參賽的。 結辯，通常是來變魔術的。 試想：一場比賽，經過了一辯、二辯、三辯的申辯、攻辯、答辯、對辯和自由辯……等到了結辯時，我方想表達的立場，通常，前面都已經表達了；想呈現的論據，通常，前面都已經呈現了；想提出的質疑，通常，前面也都已經提出了。 而表達了該表達的立場，呈現了該呈現的論據，提出了該提出的質疑後，正常情況下，就該贏了。 卻沒贏——則問題就大了。 沒贏，代表我方有些立場，講過好幾遍，但大家沒聽懂。 或聽懂了，卻依舊不接受。 又或對手的論點，你質疑，但效果不如預期。 這類問題，一旦發生，都是很結構性，很致命的！ 此時，結辯上場，自信滿滿，將前面說過的內容，用事先備好的稿子，以更慷慨激昂的方式，從從容容地，再講一次……然後，就想贏。 則若非藐視裁判智商，便是在鄙視隊友努力。 結辯要變的第一個魔術，就是他得判斷局勢勝負。 試想：廝殺之際，互有敵意，局面越緊繃，雙方越入戲——身陷其中，你越容易低估情勢、高估自己！於是對方的每句批評，聽來都強辭奪理，我方的每段陳詞，感覺都字字珠磯，甚至連裁判的每個表情，當時看來，彷彿都充滿鼓勵。 通常，那不是壞事，坐上辯士席，那是選手的自信。 但一位好結辯，卻得要努力成為一位「坐在辯士席上的觀眾」……身處隊伍之末，他看似參與，卻帶著微微疏離，雖屬一方，卻旁觀整場拉鋸，當隊友越打越認真，結辯卻總在想辦法，讓自己的眼睛保持陌生。 因為在上場前，每個結辯都必須做出一個最重要的判定： 比賽到了這階段，咱們會不會贏？ 而他跟觀眾越貼近，對現場的解讀越中立，便越能回答這問題。 不知「何時會輸」的結辯，不可能是好結辯。 於是，知道局面不利，知道自己手握最後一擊，當結辯的，慢慢就會明白一個道理： 之前那一套，要能贏，現在早就贏了！ 同樣的話，再講一次，不會有奇蹟。 這時候，還會想在台上照著腳本指點江山激昂文字的，去當一辯！還會糾結於某個攻防優勢打算繼續撲上去撕咬幾口的，去當二辯！還會一副談笑自若羽扇綸巾的……去當教練！ 緊要關頭，能感受到「大事不妙」的結辯，說起話來，自然便會有一股「焦急感」（是啊，有可能輸，當然急）。而當一個人發自內心，迫切地想表達一件事的時候，其率真的神色、無修飾的措詞、想扭轉的灼熱，便無一不在透露出訊息。 請記住，觀眾不是笨蛋，只要你一開口，他們就能分的出搞不清狀況時的裝腔作勢……與命懸一線時的捲袖對峙！ 隱隱約約，他們都會感覺到： 嗯，接下來的這三、四分鐘裡，有些事可能要不一樣了。 結辯的第二個魔術，就是他能聽懂對方立論。 常在比賽結束後，聽選手抱怨：裁判聽不懂咱們的論！ 偶爾好奇，不免當面問一聲：你聽懂了你的對手，今天用的是什麼論嗎？ 問完，十次中有八九次，他們說的，和我所聽的不是一回事。 有個問題，向來少人提——那就是當今辯論賽，已然是個高度分工的過程。 像一辯，只管申論。手裡捏著稿，背完，鬆口氣。 心理上，這傢伙就差不多是要準備下班了。 至於二、三辯，管質詢的，老盯著對手反應；管攻辯的，光留心論證缺失。 而自由辯，更別提，無非後手追前手……再一句頂一句。 高度分工的背後，風險，都在於見樹不見林。 兵荒馬亂中，整支隊伍，有誰會注意對方「說對」了什麼嗎？ 有誰會觀察，對方立論的真意呢？ 在搞懂對方企圖前，有誰會願意，暫時忍住攻擊的欲望？ 聽完論點後，有誰會暗自擊掌，說聲「靠！這個切點實在妙」？ 答案是：有的！ 有個人，他很閒。大半場比賽，只有他都沒事幹。 所以也只有他，可以認真、仔細（甚至帶點鑑賞）地聆聽對方立論……只有他，能夠（且必須）聽出有哪些偏誤，只是對方選手的一時口誤；有哪些反駁，只是錯誤理解下的過度交火。 因為最後三、四分鐘，最後一次發言。 他不能偏，不能浪費時間。 結辯的第三個魔術，就是他得幫評審下判斷。 一向認為：在辯士的養成中，獲益最大的，莫過於親身當幾次評審。 因為往往直到那一刻，他才會深刻地理解到——坐在台下時，那些老傢伙到底在想什麼？ 他才會知道，評審不是神。 每個環節，才幾分鐘？辯題兩端，哪有對錯？ 邏輯穿插，誰能嫻熟？辯手說話，何曾慢過？ 於是瞬息萬變中，但見台上立論駁論申論推論謬論悖論加上種種理論交錯出的結論——幾番唇槍舌劍，幾段俏皮話引發過幾陣大笑後，咻，比賽結束！ 然後，就要你點評、判勝負。 那一刻，十次中有七八次，評審是搞不清楚誰贏誰輸的。 好結辯，知道評審的心情。 是的，他知道那種在衣冠楚楚下的手足無措；知道眼花撩亂看著天上的妖魔混戰時，心底的那種空虛寂寞；知道如果可以，評審其實都很需要被幫助，被解惑，被撫摸…… 他知道，辯論賽，不能傻傻地「等」評審來決輸贏。 所以，他更想要「逼」評審去判勝負！ 是的，所謂結辯，其實，就是在「教台下該怎麼看比賽」的過程——你從裁判的角度，去體諒他們的難處，去揣摩他們的感觸，去思考他們糾結的是什麼。 此時，光是知道己方「說了」些什麼，沒用！**你還得要確認，裁判究竟「聽了」些什麼。** 此時，光是熟悉己方立論，沒用！你還得要聽懂，對方到底怎樣立論。 這樣一來，你才能攤開雙方的盤算，才能「客觀」地幫評審分析場上局勢，說穿對方今天準備怎麼贏？咱們又要打算怎麼破？ 你說的話，最好公道一點、敦厚一點，用詞不能那麼「絕」，態度不能那麼傾斜，適度承認自己的劣勢（沒劣勢，就不用來學結辯了），但強調依然獲勝的理由。 簡言之，你要讓裁判可以用那些話去思考——甚至，去點評。 是的，你沒聽錯，最好的結辯，就是讓評審居然可以「藉著你的話來點評」。透過你的整理，他等一下上台後，便能提綱挈領地，告訴大家剛才雙方的觀點為何？各有哪些優缺點？勝負關鍵，又在什麼地方？ 你分析得越清晰，越客觀。 他的意見，越不同，就越有壓力。 以至於，最後那個勝負的關鍵嘛…… 唔，他覺得某方在結辯時看法，相當有道理。]]></content>
<categories>
<category>黄执中</category>
<category>洛陽集</category>
</categories>
<tags>
<tag>转载</tag>
<tag>黄执中</tag>
<tag>洛陽集</tag>
</tags>
</entry>
<entry>
<title><![CDATA[洛陽集：小明何處尋？ - 黃執中的日志]]></title>
<url>%2Fcategory%2F20190527-jonas-hwang-blog-03.html</url>
<content type="text"><![CDATA[學長，打擾了！請問，若辯論的立場與辯手心中的立場相悖，怎麼解決這矛盾呢？ 在比賽中抽到「中國是否應將同性戀婚姻合法化」的辯題，打的是反方。奈何我自己一直堅定支持同性戀，並天然覺得同性戀婚姻與異性婚姻無異，應該合法化，討論時一直受自己的立場影響，根本無法安心為己方想論點，只覺得隊友句句為我方論點辯護的話，都像是反人道。 學長你說過，辯論的每一方都是為一個小明在說話，我也知道世上必有一部分人堅定地相信同性戀婚姻不應合法化，而且他們有千千萬萬的理由來解釋為什麼不應該合法化。但我偏偏與他們對立，因而我可以想出千千萬萬個理由反駁他們，現在要我在賽場上站在他們一邊，為他們說話，我卻一個支持的理由都想不出來——每一個理由，還沒說出口，就會在心中被我自己反駁掉。而且，就算最後立好了論，到場上，只怕理不直氣不壯，一開口，心就虛了 小明的例子雖然生動，但自我帶入做起來絕非易事。辯題的立場又不可能時時與我心中的立場符合。所以求學長指教，如何調整心態，打好與自己心中立場相悖的辯題呢？ 首先，我個人認為「同性戀婚姻是否應合法化」，就像「是否應禁止吃狗肉」一樣，都是爛辯題！ 之所以稱其為爛辯題，倒不是因為我最好的朋友幾乎都是同志或狗肉燉花椒真的很好吃。而是這類議題，在道理上，幾乎沒得爭……追根究底，吵來吵去，都只是出於某些人的「感覺不對」。 是的，感覺不對，因此他們「看不過去」。 像這種情況，辯論沒用。 就像你覺得屎很難吃，為什麼？ 說來說去，還不是因為「感覺不對」嘛！ 當你看著馬桶時，再多道理，有用嗎？ 事實上，每個人，心裡都有一塊他所專屬的，「感覺不對」的部位——說不出原因，講不出道理，但碰上了，就是不舒服。 嚴重的時候，那比罵他一頓，揍他一拳，還要不舒服。 更嚴重時，甚至光是看到、聽到、想到，一樣會受傷。 故那些「感覺不對」的行為，自己不碰，不夠！ 若可能，還要別人也不准碰。 是以當人數多了，這些人，就會想立下規矩，好讓大家（是的，當人數一多，就可以用「大家」這個詞了）都能免於那種不舒服。 至於那麼不舒服的事，還硬要去碰的人，顯然，是病……得罰，得矯正。 比如說，吃狗？ 例如像，同志？ 毫無道理，可就是「感覺不對」。 這，其實才是一種病。 但這種病，坦白說，我們都有，都得過。 同樣的事，對不同的對象，我們也做……正在做。 比如說，食糞？裸奔？ 例如像，戀童？亂倫？ 一個在性取向上的少數，在飲食習慣上，或許是多數。 一個在飲食習慣上的少數，到了倫理上，又可能是多數。 不同議題，站對位置時，勾肩搭背，你我都是「大家」。 一轉身，又都是可憐人。 所以，你懂嗎？小明不是壞人。 然而，他就是克制不了自己的「感覺不對」，就是無可救藥地會覺得不舒服，就是單純地不想見到某些事發生。 「你也是小明吧？」小明說。 「在不同議題上，你也當過小明吧？」 「那麼，別恨我。」小明低聲道。 「你應該能體會……大家的想法。」]]></content>
<categories>
<category>黄执中</category>
<category>洛陽集</category>
</categories>
<tags>
<tag>转载</tag>
<tag>黄执中</tag>
<tag>洛陽集</tag>
</tags>
</entry>
<entry>
<title><![CDATA[洛陽集：胜负世界的相处 - 黃執中的日志]]></title>
<url>%2Fcategory%2F20190527-jonas-hwang-blog-02.html</url>
<content type="text"><![CDATA[少爺您好。多次來這觀摩您的文章，深有感觸。看他人的困惑與留言，似覺自身多有順境，不覺大風大浪。然而今日，實有一事相傾，不吐不快，還望少爺海涵。若有幸之至，得一回覆于身，便不覺愁悶與不堪。 我對辯論興趣之至，可以用「猶如飛蛾撲火般的莽撞與衝動」來形容，我曾經幻想，自己歷經百折千回，終得以進入辯論隊，是否以後的生活就可沉浸于思辨之樂趣。然而，現在卻發現，最令我苦惱的是，與隊友之間的關係。辯論之人，多才華橫溢，棱角分明，個性顯異。由中便不難免多生衝突與嫉妒，隔閡與猜忌。順眼與冷眼，拉幫與結派，多有體現。 如此之時，還該如何繼續堅持在隊裡待下去？一眼不滿以脫口，冷眼睥睨以相向，這時還如何繼續我們的辯論之路。所以在這裡向少爺尋求解決經驗，一名辯士，究竟怎樣跟他的隊友生活相處？雖此乃個人秉性之問題，亦望在此討教一二，此致。 看完提問，不禁回想： 曾經，自己是個多麼令人討厭的辯手呢？ 社團中，計較誰出場、計較誰搭檔、計較誰打什麼位置、計較誰拿什麼名次…… 這種事，我幹過。 討論時，把倨傲當瀟灑、視固執為堅持、獨斷專擅、不給別人留面子…… 這種事，也幹過。 在台下，當面嘲笑外校同學；在台上，一邊質詢一邊敲著黑板；隊友論點不熟，皺起眉頭撇過頭，嫌其表現扯了我後腿…… 這些事，沒錯，都幹過。 而如果——如果現在的我，在您眼中是個溫文有禮風度翩翩的濁世佳公子。 那我得告訴你，是什麼改變了我。 是勝負。 是我一直想贏，也一直有機會贏的過程，改變了我。 贏夠了，有自信了。許多事，就不在乎了。 「下午比完賽，腦子裡全是孔雀開屏的畫面。」傍晚聊到示範賽時，馬薇薇有感而發：「周玄毅最後的結辯，就像拖著一襲華麗的尾羽……忽然一轉身，咱們就輸了。」 聽完，我大笑。 我知道，那不是羅太的坦然，是因為她，贏夠了。 「總有人說，那場2001年的冠亞賽該我們贏。」好幾次，聽周玄毅強調：「這麼說，若是想安慰我，那好意心領；但他若是真心這麼認為……則腦子顯然進水了！」 聽完，我大笑。 我知道，那不是玄毅的大氣，是因為他，贏夠了。 「我覺得你剛才那個回應很好。」討論比賽時，漸彪說：「待會可以跟秋樺說。」 「秋樺啊，漸彪有個論點很不錯，結果啟發了我一個新回應。」我說：「妳聽聽看有什麼問題？」 聽完，漸彪偷笑。 他知道，那不是我倆的謙虛，是因為他跟我，贏夠了。 是的，英雄惜英雄，不是他們生性特別坦然大氣謙虛豁達。 是因為，他們都贏夠了。 衝突與嫉妒，是因為還有些東西，努力想證明。 隔閡與猜忌，是因為還有些東西，擔心得不到。 順眼與冷眼，是因為還有些東西，等待被品評。 拉幫與結派，是因為還有些東西，會需要靠自己的朋友來肯定。 追逐的身影，總是狼狽的。 等追到了，整整衣衫，講儀態，才有可能。 所謂「優雅地追逐」，其實，是另一種不在乎。 圈內多年，見太多橫眉冷眼的少年，有自信後，慢慢慈眉善目；見太多羞澀怯生的笑臉，屢屢失落，逐漸偏激尖酸——在乎的，得不到，多少人能從容化解？一將功成萬骨枯，慈眉善目背後，多少人因辛酸而心酸而尖酸？衣食足，方知榮辱；榮辱足，方存忠恕。在勝負的世界裡，美德要靠多少機運？多少犧牲？ 所以尖酸割出的傷，善目要去流淚。所以偏激燒成的痛，慈眉為之不展。所以溫良恭儉讓，不全然出於某個人的境界高低品格善惡樣板好壞，在勝負的世界裡，它只是你勝利前的一種可能……等贏夠了，才是責任。 所以，去吧。請趁著年輕，放心去羨慕，去嫉妒，去猜忌，去厭惡。 因為無論如何，你的勝負，或別人的勝負…… 最後會給出救贖。]]></content>
<categories>
<category>黄执中</category>
<category>洛陽集</category>
</categories>
<tags>
<tag>转载</tag>
<tag>黄执中</tag>
<tag>洛陽集</tag>
</tags>
</entry>
<entry>
<title><![CDATA[如果能，你夠強！ - 黃執中的日志]]></title>
<url>%2Fcategory%2F20190527-jonas-hwang-blog-01.html</url>
<content type="text"><![CDATA[引言 自从网易博客停止服务后，想找少爷的文章就变得非常困难，比如收藏夹里这篇 如果能，你夠強！ 就无迹可寻。今天终于找到了少爷博客的存档（不过需要科学上网），于是赶紧备份下来，以备查阅。后续应该还会陆陆续续搬运过来，具体目录请见 这里 。 正文 智慧型手機出現後，我們或多或少，都曾遇到過像這樣的「社交羞辱」：那些說好陪你吃飯，一起開會，共同敘舊，約會喝茶的傢伙……人坐對面，心在別的地方。 低頭，傳訊，按讚，打卡。 他們用那麼簡單地動作，當面向你傳達：此時，此刻，**即使隨意和那些他「真正」在意的人隔空打屁幾句，哼哼哈哈，都好過陪你這頓飯，這個會，這談話，這杯茶。** 在我心中，你其實沒那麼重要。 這種羞辱，老一輩的人不能忍！ 喔，我當然不會天真地認為，手機出現前，人人都能喜愛他眼前的聚會。 只不過，那時他們沒選擇。 科技，讓人自由。 但「自由」的本質，卻恰卻是一種「羞辱」。 是的，就像人，都是在有了選擇職業的自由後，才有機會，去「羞辱」他們家傳的祖業。 所以世家子弟，終於可以做畫家，不用拚命應科舉。 以至老店後人，也能跑去當船員，不用認命熬羹湯。 更老一輩的人，面對這種「自由」，也同樣會覺得傷心，覺得被羞辱。 我自豪的身分，原來，對你其實不重要？ 我自傲的技藝，原來，對你其實不重要？ 言論自由、宗教自由、婚戀自由、思想自由、居住與遷徙的自由……每一種自由的機會，選擇的結果，換個角度看，其本質都是否定與羞辱。 是的，自由的意義，就在於你必須承認：原來你所在意的，對人家來說不重要；原來你所信仰的，對人家來說不重要；原來你所珍惜所熱愛，甚至願意為之犧牲青春、奉獻性命的。 對人家來說，根本一點都不重要。 不能忍受羞辱，便難擁抱自由。 要想避免羞辱，就得限制自由。 故「自由」的反義詞，不是「奴役」，而是「尊重」。 尊重傳統、尊重師長、尊重上帝、尊重律法、尊重族群、尊重國家、尊重他人的感受與感傷……每一種尊重的方式，體諒的代價，換個角度看，其本質都是妥協與退讓。 你願意痛快地羞辱人，然後，也痛快地被人羞辱嗎？ 如果能，你夠強！ 也它馬的夠流氓！ 可人生在世，真自由——惟強者，與流氓得享。]]></content>
<categories>
<category>黄执中</category>
<category>辯士的思索</category>
</categories>
<tags>
<tag>转载</tag>
<tag>黄执中</tag>
<tag>辯士的思索</tag>
</tags>
</entry>
<entry>
<title><![CDATA[Hexo文章发布环境的自动部署02-Hexo配置]]></title>
<url>%2Fcategory%2F20190525-hexo-autodeploy-two.html</url>
<content type="text"><![CDATA[引言 本文承接自 这篇文章 ，在配置完 Git 及完成其自动配置脚本后，接下来就准备对 Hexo 本身动手啦！ 正文配置 Hexo 发布环境创建新 Repository 打开浏览器并登陆到 GitHub 网站，在个人首页上切换到”Repositories”标签页并点击右侧的”New”按钮进入新建 Repository 界面： 其中”Repository name”可自行填写，因为 Hexo 发布环境中可能会涉及密码或 client_secret 等不宜公开的内容，所以发布模式选择”Private”更为安全。填写完毕后，点击下方的”Create repository”完成创建。 修改并上传 Hexo 文件拷贝 Hexo 文件 在终端中运行 git clone https://github.com/joe136685182/HexoBlog.git 将新建的 repository 克隆到本地（请将命令中的 GitHub 链接替换为你个人的 repo 地址），然后将本地的 Hexo 文件复制到生成的文件夹中，如下图： 配置 .gitignore 文件 因为我们只需要最基本的 Hexo 文章发布环境，所以可以随时自动安装的 Hexo 程序、相关的Node.js 模块以及自动生成的 public 文件夹都是不需要上传的。按照这个原则，我们可以通过配置 .gitignore 文件来屏蔽这些内容。 在终端中进入刚刚克隆出来的 HexoBlog 文件夹，然后执行以下命令： 123$ cd HexoBlog$ touch .gitignore$ vi .gitignore 在打开的编辑界面中输入以下内容，并保存退出： 123456789node_modules/public/.DS_StoreThumbs.db*.log.deploy_gityarn.lock*.swap*.iml 上述配置分别屏蔽了 Node.js 模块安装目录、自动生成的文章目录、 macOS 自动生成的 .DS_Store 文件、图片缩略图 Thumbs.db 文件、日志文件、Hexo 发布文章到 GitHub 前自动生成的缓存目录以及 Hexo 生成文章时自动产生的各个临时文件。 除这些文件/文件夹以外，如果有其它屏蔽/添加文件的需要，可以自行访问 这里(英语) 或 这里(中文) 学习 .gitignore 的配置语法。 配置主题文件（可选） 如果你的 Hexo 通过 git clone 的方式配置了第三方主题（比如本站就使用了 NexT主题 ）的话，在 themes/ 目录下会有相应的文件夹，如果此时直接通过 git add 命令添加主题文件夹，会有如下错误提示： 123456789101112131415$ git add themeswarning: adding embedded git repository: themes/nexthint: You've added another git repository inside your current repository.hint: Clones of the outer repository will not contain the contents ofhint: the embedded repository and will not know how to obtain it.hint: If you meant to add a submodule, use:hint: hint: git submodule add <url> themes/nexthint: hint: If you added this path by mistake, you can remove it from thehint: index with:hint: hint: git rm --cached themes/nexthint: hint: See "git help submodule" for more information. 这是因为 Git 检测到了，要添加的 themes/next 目录是来自另一个 Git 项目，不能直接作为本项目的文件进行上传。遇到这种情况有两种解决方法： 将主题配置为子模块 这也是上文错误提示中建议的一种处理方式。这样做的好处是操作简单，且能保证每次克隆本项目时，作为子模块的主题能跟随作者的更新保持同步；但这会导致每次克隆之后，我们对主题配置文件 _config.yml 及其它文件的修改都会丢失，需要重新配置。 如果选择这种解决方法，只需在 HexoBlog/ 目录下执行 git submodule add git-url themes/next 即可，其中 git-url 需要替换为主题的 GitHub 地址。要使用带了子模块的项目有一些 注意事项 需要注意，请务必了解。 清除主题中的 Git 相关信息 这种处理方式可以保留对主题配置文件及其它文件的修改，但如果主题作者对主题进行了更新，则在同步更新主题时会比较麻烦。因为本站使用了 Gitment 以实现文章评论，对主题配置文件进行了修改，而这种处理方式可以保留修改，且在克隆时更简单快捷，所以选择使用这种处理方法。 如果选择这种解决方法，可以通过以下命令清除主题的 Git 信息： 12$ cd themes/next$ rm -rf .git* 这样就完成了 Git 信息的清除，此时再通过 git add 命令添加 themes/ 目录就不会再有错误提示了。而当主题作者进行了更新要进行同步的话，就只能删除当前的主题目录，重新克隆最新的主题，然后重新进行配置，这也是这种解决方法的不足之处。 将处理后的 Hexo 目录同步到 GitHub 到这里，对 Hexo 目录的处理就基本完成了，在终端中进入 HexoBlog 目录，执行 git status 命令，可以查看到待同步文件信息。接下来执行 git add * 将所有变更添加到待同步列表中，此时 Git 会根据 上文 配置的 .gitignore 文件，过滤掉相应的文件和文件夹。 此时再次执行 git status 命令，可以看到除了 .gitignore 文件以外，所有变更都已经进入待提交队列了，所以还需要执行 git add .gitignore 命令将 .gitignore 文件也添加进去。一切准备就绪后，执行 git commit -am "first commit of hexo" 进行提交，并执行 git push 推送到 GitHub 上。 编写 Hexo 自动初始化脚本将 Hexo 克隆到本地并初始化 上文已经将 Hexo 目录同步到 GitHub 了，接下来说一下如何将 Hexo 目录部署到本地并进行初始化。 首先在终端中进入要部署 Hexo 环境的目录下，执行 git clone git-url 将之前处理过并上传的 Hexo 目录拉取到本地（假设没有添加第三方主题，或主题已经 照此 处理），其中 git-url 需要替换为本项目的 GitHub 地址（如 https://github.com/joe136685182/HexoBlog.git ），然后执行以下命令完成初始化： 1234$ cd HexoBlog$ npm install --save hexo$ npm install$ npm install --save hexo-deployer-git 如果在上传 Hexo 目录时，使用了 这种方法 处理第三方主题，则需要额外处理子模块的同步问题，具体操作方式请参考 这篇文章 。 在完成初始化之后，就可以直接通过 Hexo new title 命令进行新建文章操作、通过 Hexo clean && Hexo g -d 命令发布文章了。请注意，在每次新建、修改、发布文章后，或者调整了 Hexo 及主题的设置后，都建议执行以下命令，将变更及时同步到 GitHub 上，避免变更丢失： 1234$ Hexo clean$ git add *$ git commit -am "add/modifiy articles or change config files"$ git push 将初始化命令编写为脚本 每次更换环境都要手动完成初始化，其实可以将初始化命令编写成自动化脚本。进入 HexoBlog 目录，执行以下命令： 123$ touch init_hexo.sh$ chmod +x init_hexo.sh$ vi init_hexo.sh 在打开的编辑界面中输入以下内容，并保存退出： 1234#!/bin/bashnpm install --save hexonpm installnpm install --save hexo-deployer-git 然后接着执行以下命令，将该脚本同步到 GitHub 上： 123$ git add init_hexo.sh$ git commit -am "add auto-deploy script"$ git push 到这里，脚本的编写和同步就完成了。 新环境下快速部署 Hexo 目录 假设现在换了一台新电脑（系统为 macOS 或某个 Linux 发行版），结合 这篇文章 中的内容，只要安装好Node.js 环境以及 Git 工具，即可实现 Hexo 目录的快速部署。 首先检查 Node.js 环境及 Git 工具已经安装完毕，然后将 之前 准备好的 SSH Key 部署文件夹拷贝到新电脑上（假设为 ~/GithubKey 目录），在终端中执行以下命令完成 Git 工具的配置： 12$ cd ~/GithubKey$ ./init_github.sh 部署完 SSH Key 之后，在终端中执行以下命令，完成 Hexo 环境的部署和初始化： 1234$ cd ~$ git clone https://github.com/joe136685182/HexoBlog.git$ cd HexoBlog$ ./init_hexo.sh 其中执行 git clone 命令时要记得将 GitHub 地址替换为自己的项目地址。到这里就完成了 Hexo 文章发布环境的部署和初始化，一共只需要执行6个命令，而且还能实现文章的备份，一举两得。如果你比我还懒的话，后4个命令还可以集成到 GithubKey/init_github.sh 中，真正实现一键部署，这个就留给有缘人你自己去折腾吧～ 后记 到这里终于记录完了这个小任务的全过程，真的我保证，上手试一下就能发现这真的是个小任务，不知道为什么写下来会这么长😂 搞 Hexo 还是蛮有意思的，就是部署不太容易，文章也容易丢。考虑到以后经常要用 rMBP 以外的电脑，换电脑是个麻烦事，所以还是查了一些资料，把这个脚本搞了出来。这两天的小折腾也让我学习了蛮多 Git 相关的知识，果然懒和好奇是第一驱动力丫。好了我要去洗菜了，白白～]]></content>
<categories>
<category>笔记</category>
</categories>
<tags>
<tag>笔记</tag>
<tag>Hexo</tag>
<tag>Git</tag>
</tags>
</entry>
<entry>
<title><![CDATA[Hexo文章发布环境的自动部署01-Git配置]]></title>
<url>%2Fcategory%2F20190524-hexo-autodeploy-one.html</url>
<content type="text"><![CDATA[引言 Hexo 博客搭建完了之后，文章发布虽然方便，但发布流程依赖于本机上已经部署好的 Hexo 环境，当要发布文章时，如果部署好的电脑不可用（坏了/不在身边），或者换了新电脑，总之面对一台空荡荡的新电脑，要重新人工搭建已有环境非常麻烦，且之前发布过的文章（md文件）会丢失。 为了避免这种情况，我们可以通过 Github 将文章及发布环境打包，做成一键备份/部署的脚本，这样在迁移到新环境后，只需简单的操作即可完成 Hexo 文章发布环境的部署，同时实现文章的备份及同步功能。 正文环境准备 本文以 macOS 10.14.4系统为例，具体命令及路径请根据自己的情况进行调整。 在开始之前，请确定已安装 Node.js 环境并配置好系统环境变量，然后在终端运行 node -v 查看 Node.js 版本，运行 npm -v 查看 NPM 版本，没有出现报错说明 Node.js 环境正常。如果没有安装 Node.js 环境的话，可以参考 本文 进行安装 安装并配置 Git安装 Git macOS 已经自带了 Git，如果没有安装，或者是其它系统/平台，可以参考 官网教程 ，或自行谷歌查找教程。对于 macOS 及 Windows 系统，还可以通过 这里 下载带 GUI 界面的安装包。 安装完成后，在终端运行 git --version 查看 Git 的版本，没有出现报错说明Git已经正确安装。 配置 Git 连接 GitHub设置 GitHub 用户名和邮箱 首先，假定已经有了一个 GitHub 账号。接下来，通过终端配置名字和邮箱： 12$ git config --global user.name "John Doe"$ git config --global user.email yourmail@gmail.com 其中”John Doe”替换为你的 GitHub 用户名，也就是个人首页链接 https://github.com/username 中的username；yourmail@gmail.com 替换为该 GitHub 账号设置的 Public email 地址。 配置完成后，可以通过 git config —list 命令检查配置是否正确。注意，如果 GitHub 账号没有设置 Public email 或者设置的 Public email 与配置不符，均会导致后续 Git 同步出错。 配置 SSH Key 本地 Git 仓库与 GitHub 仓库之间进行数据传输时，是通过 SSH 进行加密通信的，而 SSH Key 就是加密通信时用于验证身份的密钥。 生成 SSH Key 打开终端，执行 ssh-keygen -t rsa -C "yourmail@gmail.com" 生成 SSH Key 密钥对。其中 -t 参数指定了密钥对的加密协议为 RSA ，在本次密钥对生成中不能更换为其它协议；-C 参数设置的是生成密钥对的备注，可以自行填写为其它内容。 输入上述命令后回车执行，会提示询问生成密钥对的存放路径（默认为 ~/.ssh/id_rsa ），一般情况下保持默认，直接回车确认即可；确认存放路径后，程序会提示”设置密钥对密码”，此处直接回车跳过（即不设置密码），然后在接下来的”确认密码”环节也直接回车跳过，即可完成 SSH Key 的生成步骤。 注意，如果选定的密钥对存放路径中已经有同名文件，会提示是否覆盖，请根据实际情况选择覆盖或重新设定存放路径。生成 SSH Key 的过程可参考下文： 1234567891011121314151617181920212223$ ssh-keygen -t rsa -C "yourmail@gmail.com"Generating public/private rsa key pair.Enter file in which to save the key (/Users/charles/.ssh/id_rsa): /Users/charles/.ssh/id_rsa already exists.Overwrite (y/n)? yEnter passphrase (empty for no passphrase):Enter same passphrase again: Your identification has been saved in /Users/charles/Desktop/id_rsa.Your public key has been saved in /Users/charles/Desktop/id_rsa.pub.The key fingerprint is:SHA256:uBAtSvDY8ucTcMZAUjghqQJnZx/xcOAl7X4hv/qNN+I charles@bogonThe key's randomart image is:+---[RSA 2048]----+|=*+ =+o ||**oooo.*. ||=+=o*.oo. ||o+ = o..o . ||. o + ..So . || o o .. o || o . . . || . ooo || .+Eo.. |+----[SHA256]-----+ 配置 GitHub 在完成了 SSH Key的生成步骤后，可以在指定的存放路径下找到两个文件，即为生成的 SSH 私钥与公钥，文件名在生成密钥对时设置，默认情况下分别为 id_rsa 和 id_rsa.pub 。 打开浏览器，访问 GitHub 并登陆自己的账号，点击右上角个人头像并选择下拉菜单中的”Settings”： 在左侧找到”SSH and GPG keys”选项，然后点击”SSH keys”行右侧的”New SSH key”按钮，进入新增 SSH Key 界面： “Title”栏为该 SSH Key 的标题，可自行随意填写；然后在”Key”栏中填入之前生成的 id_rsa.pub 文件中的内容，具体内容查看方法如下： 12$ cat ~/.ssh/id_rsa.pubssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC0wnQ2DVRZQ8LZ4Q2PbGDaEriUm4B+k9Xn/0kM1Z81xW4tF73hG7s7I9/GRRDD/ZWoWJesTEZpUaRNzb3fecofcQOVEgV0EYKeReHcI2CEhJcTGpT3Sosm0R5XZQytH/KUhE3gHPaBhSq5HvpjsjdvzcLwjwXzEut59bVnNXum0JfT2IiY1e7RxSgN28P0rgwGRVfiLjl0Lpa5lm/2L24MzQehIMb4bkgl+odbjCUJHr8RN/Xwj+O7cQyNBkNEYVhR58daG8vPVAaAI1ZvbUrh7i6YE9HjftRmsRtUzfMqna/OtMR2QC0Efao4A/rE4s/pCOJkwBDOmq38SkM6wmuF yourmail@gmail.com 将完整的文件内容（包括开头的”ssh-rsa”和末尾的邮箱/备注）复制并粘贴到 GitHub 网页的”Key”栏中： 点击”Add SSH key”保存即可。保存完成后，如果在生成 SSH 密钥对时没有使用默认的存放路径，则需要配置 SSH 连接的 Key 文件路径，下次有空再写应该怎么处理多 Key 文件的问题。此处默认 SSH Key 文件路径为 ~/.ssh/id_rsa 及 ~/.ssh/id_rsa 。 在终端中执行 ssh -T git@github.com 测试连通性，如果是第一次通过 SSH 连接 GitHub 的话，会提示”目标服务器未确认，是否保存 RSA key 信息并继续”，此处输入”yes”并回车即可。当出现下文提示时，说明 SSH Key 已经配置成功： 123456$ ssh -T git@github.comThe authenticity of host 'github.com (13.229.188.59)' can't be established.RSA key fingerprint is SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.Are you sure you want to continue connecting (yes/no)? yesWarning: Permanently added 'github.com,13.229.188.59' (RSA) to the list of known hosts.Hi joe136685182! You've successfully authenticated, but GitHub does not provide shell access. 编写 SSH Key 自动部署脚本 当换到一台新的电脑上时，我们肯定不想再重复一遍生成、配置、测试 SSH Key 的过程，所以可以把已经生成的密钥对文件复制出来，并通过 Shell 脚本自动复制到目标目录。在终端中执行以下命令： 12345$ mkdir GithubKey$ cd GithubKey$ touch init_github.sh$ chmod +x ./init_github.sh$ vi init_github.sh 在打开的编辑界面中输入以下内容，并保存退出： 1234#!/bin/bashcp ./.gitconfig ~/cp -p ./id_rsa* ~/.ssh/ssh -T git@github.com 第一行设置了 Shell 解释器的路径，可以根据具体情况进行调整；第二行将 Git 配置文件复制到 ~ 目录下，即 此处 配置的 GitHub 用户名和邮箱；第三行将之前生成的 SSH Key 文件拷贝到 ~/.ssh/ 目录下；第四行通过 ssh 命令测试与 GitHub 的连通性。 执行上述命令会生成 GithubKey 文件夹，然后将 ~/ 目录下的 .gitconfig 文件及 ~/.ssh/id_rsa 文件（即上文生成并在 GitHub 网站上配置好的 SSH Key 文件）拷贝到 GithubKey/ 目录中。 只要将该目录（也可打包为 zip 文件便于传输）拷贝至新环境下，安装完 Git 工具后，进入目录中执行该脚本文件，即可自动完成 Git 的配置。 后记 本来想一篇文章就把这个内容全部记完，但没想到单单一个 Git 与 GitHub 的配置就那么多内容，所以还是拆分成两篇吧，第二篇 在这里，先吃饭去了～]]></content>
<categories>
<category>笔记</category>
</categories>
<tags>
<tag>笔记</tag>
<tag>Hexo</tag>
<tag>Git</tag>
</tags>
</entry>
<entry>
<title><![CDATA[Electron笔记02-Hello World！]]></title>
<url>%2Fcategory%2F20190523-electron-note-two.html</url>
<content type="text"><![CDATA[引言 在 前一篇文章 中介绍了在macOS上搭建Node.js+Electron的过程。准备好了开发环境，接下来当然是开始搞事情啦！作为一只程序猿，搞事情从哈喽沃德开始！ 第一个Electron AppElectron App的结构 这第一个App的名称暂定为 “test-app” ，它的基础文件结构如下： 1234test-app/├── package.json├── main.js└── index.html 这个结构是Electron App最简单最基础的文件结构，在这些文件里，我们可以定义、编写自己的应用的样式、功能等等。后期随着应用功能的增加，可能会遇到更复杂的组织形式。 各个文件的内容package.json package.json文件是一个Electron App的基础配置文件，基本内容如下： 12345{ "name" : "test-app", "version" : "0.1.0", "main" : "main.js"} 其中”name”属性记录了应用的名称，可以自定义；”version”属性记录了应用的版本，可用于应用更新、版本控制等；”main”属性则指定了主进程的入口文件，在下文中会介绍。 作为一个标准的json文件，在这个文件中不能有任何注释符号，如//、/*、#等。同时还需要遵守其它json格式规范，具体细节就不赘述了。 main.js main.js文件（文件名可在package.json中自行定义）是Electron主进程的入口文件，基本内容如下： 123456789101112131415161718192021222324252627282930313233const electron = require('electron'); // 引用 Electron 模块。const app = electron.app; // 控制应用生命周期的模块。const BrowserWindow = electron.BrowserWindow; // 创建原生浏览器窗口的模块// 保持一个对于 window 对象的全局引用，不然当 JavaScript 被 GC 后，window 会被自动地关闭var mainWindow = null;// 当所有窗口被关闭了，退出。app.on('window-all-closed', function () { // 在 OS X 上，通常用户在明确地按下 Cmd + Q 之前，应用会保持活动状态 // if (process.platform != 'darwin') { app.quit(); // }});// 当 Electron 完成了初始化并且准备创建浏览器窗口时，这个方法就会被调用app.on('ready', function () { // 创建浏览器窗口。 mainWindow = new BrowserWindow({ width: 800, height: 600 }); // 加载应用的 index.html mainWindow.loadURL('file://' + __dirname + '/index.html'); // 默认打开开发工具 // mainWindow.openDevTools(); // 当 window 被关闭，这个事件会被发出 mainWindow.on('closed', function () { // 取消引用 window 对象。如果你的应用支持多窗口的话，通常会把多个 window 对象 // 存放在一个数组里面，但这次是单窗口应用，只有一个 window 对象，退出时要销毁 mainWindow = null; });}); 当App启动时，Electron主进程会根据package.json中配置的main入口文件，找到并执行。在main.js文件中，Electron完成了主窗口的初始化及创建后，会通过loadURL()函数加载主界面，而这个主界面就由接下来介绍的index.html文件定义。 index.html Electron在根据main.js完成了主窗口的初始化及创建后，会通过loadURL()函数加载index.html作为应用的主界面，基本内容如下： 12345678910<!DOCTYPE html><html> <head> <title>Hello World!</title> </head> <body> <h1>Hello World!</h1> Hello World! Hello Charles! This is your first Electron application, nice try! </body></html> 运行程序 在按照上文完成三个文件的创建流程之后，一个最简单的Electron App就编写完成了。接下来就运行一下这个程序看看效果吧！ 打开终端，切换到应用项目所在文件夹（也就是上述三个文件所在的文件夹），然后输入以下命令： $ electron . Electron就会按照配置文件，初始化并创建主窗口，然后加载index.html文件，效果如下图： 顺手记录一下，macOS下的截图快捷键是 shift+command+4。 后记 到这里，第一个Electron App就跑起来了。所以其实我们可以看到，Electron应用本质上就是通过将浏览器窗口封装为一个应用，然后渲染网页作为界面，并通过JavaScript作为应用逻辑代码的实现语言。所以说，Electron真的是前端友好型语言啊！]]></content>
<categories>
<category>笔记</category>
</categories>
<tags>
<tag>笔记</tag>
<tag>Electron</tag>
</tags>
</entry>
<entry>
<title><![CDATA[Electron笔记01-开发环境的准备]]></title>
<url>%2Fcategory%2F20190523-electron-note-one.html</url>
<content type="text"><![CDATA[引言 计划用Electron把账本导出脚本GUI化，之前是通过Python3 + Excel文件实现的。虽然基本能满足自己的基本需求，但还是太简陋功能太少了。 在选择GUI方案时，考虑了WPF+C#、Xcode+Swift、Electron等几个方案，但出于以下几点考虑，最后选择了Electron： 第一点是因为目前主力用的rMBP，搞WPF实在是自找麻烦； 第二点是希望这个小玩意儿能跑在mac之外的平台上，毕竟除了手头这台rMBP剩下的都是Win平台，所以Swift不太行（主要是我的Swift水平不行XD）； 再有一点就是想学习一下Node.js，开阔一下眼界，毕竟现在掌握JS的人就能主宰世界[手动斜眼]。 所以就决定是你了，Electron！ 正文系统环境 机器：MacBook Pro (Retina, 13-inch, Late 2013) 系统：macOS Mojave 10.14.4 编辑器：Visual Studio Code 1.32.3 Shell：macOS自带Terminal 搭建开发环境安装Node.js 对于Node.js，有以下几种安装方法可选（建议使用安装包安装）： 1. 安装包安装，到 官网 下载PKG安装包后双击运行，安装提示一步一步执行即可。截至目前最新的版本为 node-v12.3.1 2. 源码手工编译，到 官网 根据自己的平台下载源代码压缩包，解压后手动编译并安装即可。 3. 通过Homebrew安装：在终端中执行brew install node即可。 安装完成后，在终端中分别执行npm -v和node -v查看安装的版本，如果没有报错说明Node.js安装完成。 安装Electron 1. 通过npm安装Electron。建议将Electron安装为全局模式，以便在终端中进行调用。具体安装命令为：npm install electron -g --save 2. 修改Bash配置，将Electron加入系统环境路径： 12$ cd ~$ vi .bash_profile 在.bash_profile文件中添加以下语句： 12#Setting PATH for Electron/Node.jsPATH="/Users/charles/nodejs/npm_global/bin:${PATH}”export PATH 保存退出后，执行source .bash_profile使配置生效 安装及配置完成后，执行electron -v查看安装的版本，如果没有报错说明Electron安装完成。 后记 到这里，Electron就安装完成了，接下来就是喜闻乐见的Hello World环节啦！吃饭去，白白～]]></content>
<categories>
<category>笔记</category>
</categories>
<tags>
<tag>笔记</tag>
<tag>Electron</tag>
</tags>
</entry>
<entry>
<title><![CDATA[第一篇文章]]></title>
<url>%2Fcategory%2F20190522-first-article.html</url>
<content type="text"><![CDATA[Hexo终于搭建完成了，Gitment也配置上了，测试一下文章效果如何。Hexo支持Markdown，看来以后还得学习一下Markdown语法。折腾这些玩意儿虽然没什么实际价值，但还是挺有趣的。 测试一下图片功能这是塞尔维亚贝尔格莱德老城区里，Casanova餐厅的招牌牛排。听说现在已经变成网红店了？ 这张合照也是在贝尔格莱德老城区拍的，在萨瓦河与多瑙河合流处的卡拉梅格丹城堡边上。至今我仍然非常想再去一次。 测试一下PicGo的上传效果 下面的内容没啥意思了 在MarkDown中，如果使用了尖括号对<和>，会被文本默认为HTML语句。这将导致尖括号本身及尖括号中的内容都不会被显示。 解决方法：使用转义字符。使用 & lt; 代替 < , 使用 & gt; 代替 > 。例如要输出<a>，则需要写为& lt;a& gt;]]></content>
<categories>
<category>随笔</category>
</categories>
<tags>
<tag>测试</tag>
<tag>随笔</tag>
</tags>
</entry>
<entry>
<title><![CDATA[Hello World]]></title>
<url>%2Fcategory%2F20190521-auto-hello-world.html</url>
<content type="text"><![CDATA[Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub. Quick StartCreate a new post1$ hexo new "My New Post" More info: Writing Run server1$ hexo server More info: Server Generate static files1$ hexo generate More info: Generating Deploy to remote sites1$ hexo deploy More info: Deployment]]></content>
<categories>
<category>测试</category>
</categories>
<tags>
<tag>测试</tag>
</tags>
</entry>
</search>