我们现在最需要的世界杯, 来了
2022-11-18我们现在最需要的世界杯, 来了
4年一次世界杯终于即将在卡塔尔拉开大幕.
这一次4年的等待,似乎是如此漫长.
我们经历了如此不平凡的, 曲折的, 难忘的4年.
疾病, 战争, 衰退, 竞争, 封闭, 让我们深深体会到了死亡, 焦虑, 悲观, 不安.
可是也让我们历练, 成长.
面对光怪陆离的世界, 我们有了一切本就如此的洒脱.
面对奇形怪状的事件, 我们有了做好自己的觉悟.
如今, 我们终于等到了新的世界杯.
这是全人类努力的结果.
在阴霾笼罩下,
我们依然渴望着每一个进球,
每一次激情的进攻,
每一次强悍的防守,
团结一致的团队,
追求胜利的激情,
永不服输的精神,
终于又来了.
足球仅仅是一项运动,
它不能结束疫情,
也不能结束战争.
但是至少,
它能让我们暂时忘记那些糟糕的境遇,
舔舐伤口,
重聚信念,
它能让我们怀念起那些光辉岁月,
勇敢面对,
绝不低头.
加油, 失去多名主力但依然强大的卫冕冠军法国队!
加油, 拥有豪华攻击线的五星巴西队!
加油, 无数球迷热爱的铁血世界杯四冠王德国队!
加油, 迷人的阿根廷队!
加油, C罗和梅西, 祝你们最后一届世界留下最美好的回忆!
加油, 我的家人和朋友,
足球万岁!
生命万岁!
求索集-十-本地部署墨滴
2022-08-20求索集-十-本地部署墨滴
目前, 我的写作流程是:
- 使用Hexo新建一篇文章
- 用Typora程序写作, 写作时使用Markdown语言 (此处再次安利, 第一是Markdown, 写作文章非常优秀的标记语言, 开源,简单易学, 兼容HTML代码, 可近乎完美转换为PDF或者网页, 是当今的绝对主流; 第二是Typora, 虽然现在不免费了, 但是作为一款非常精致的支持Markdown的写作软件, 干净, 雅致, 简洁的写作环境非常能让我这样的一写作文就想睡觉的学渣都能专心写作, 一顿烤串的钱, 安利安利)
- 使用Hexo将文章发布到GitHub上的Blog页面
- 同时, 使用墨滴 将Markdown转换为微信公众号支持的样式, 然后发布到微信公众号
将Markdown转换为微信公众号支持的样式是非常重要的一步, 因为微信公众号并不支持Markdown. 这点其实也挺无奈, 我们似乎从上到下都特别喜欢搞自己的一套标准, 但问题是, 第一, 这套标准不兼容世界主流标准; 第二, 其实我们建立的标准完全是建立在人家标准基础之上的, 并非是我们自主研发的. 我们”借鉴”了别人的技术, 然后建立了一套不兼容别人的标准, 这个话题将来我会展开讨论, 此处不做展开.
这里的转换我比较推荐墨滴, 但墨滴是个在线工具, 我对这种基于网页的在线工具一向有个奢望:
有没有可能部署到本地? 这样哪怕有一天网站不经营了, 我也能继续使用
程序和数据本地化, 也是我比较在意的事情, 不仅仅是隐私, 更为了安全.
非常棒的是, 墨滴支持本地部署, 而且是完全开源的. 我的天, 本地, 开源, 免费, 易用, 简直就像给女生送花一样, 直接击中我的红心~~~
部署过程很简单, 先说环境准备:
- Windows+ IIS. 其他Web服务器应该也行, Linux应该也没问题, 但我就会用Windows, 就会用IIS, 所以咱就Windows + IIS了哈
- 安装node.js, 安装最新版本就行, 安装时选择默认设置即可
下面就开始本地部署墨滴:
从Github下载墨滴源文件, 下载完应该是个zip包, 文件名类似 markdown-nice-master.zip
解压缩这个压缩包, 然后进入解压缩后的文件夹, 执行
npm i --legacy-peer-deps #这一步是为了安装需要的依赖. --legacy-peer-deps不加的话会报错 npm run build #打包墨滴程序
打包完毕后, 就会在文件夹里看到多了一个build文件夹
这个build里面就是墨滴的程序了, 看到index.html了吧, 这就是墨滴的主页了
IIS里新建站点, 把站点目录定位到build文件夹, 设置好本地端口, OK了您内
在防火墙李把端口打开, 然后给IIS服务器配置一个公网ip和域名, 你就能在任何地方使用专属于自己的墨滴了
求索集 - 九 小潘小潘告诉我, 拜仁慕尼黑还有多少德国球员
2022-08-19求索集 - 九 小潘小潘告诉我, 拜仁慕尼黑还有多少德国球员
2022-23赛季, 欧洲各大联赛重燃战火, 今年的转会市场依然火爆, 切尔西完全没有因为阿布的离去影响转会, 1.87亿欧元转会投入冠绝欧洲.
1、切尔西 1.87亿欧元
2、巴萨 1.53亿欧元
3、拜仁 1.38亿欧元
4、阿森纳 1.32亿欧元
5、西汉姆联 1.24亿欧元
6、曼城 1.22亿欧元
7、热刺 1.2亿欧元
8、诺丁汉森林 1.19亿欧元
9、巴黎 1.07亿欧元
10、利兹联 1.06亿欧元
不出意外, 第四一定是我厂…
这里值得注意的是, 德甲巨人, 欧洲王者, 南大王, 真伦敦之王拜仁慕尼黑花了1.38亿. 不过问题来了, 大手笔引进了荷兰的德里赫特和赫拉芬贝赫, 还有塞内加尔的马内, 德国球迷难免就含糊了, 作为德国国家队的摇篮, 拜仁慕尼黑还有多少德国球员? 都是外援了, 德国国家队可怎么办? 要知道今年可是世界杯年, 多少德国球迷都备好了巴伐利亚啤酒和大香肠等着看德意志军团一雪2018世界杯的耻辱, 重铸辉煌呢.
正好数据分析学到这里了, 咱们就请小潘告诉我们, 拜仁还剩几个德国本土球员吧.
这里的小潘不是大郎的老婆, 西门大官人的相好, 打虎英雄的仇敌, 我们的金莲女士. 小潘是我给Pandas起的外号. Pandas, Python的数据分析库, 大名鼎鼎的数据分析工具, 数据分析师不可不会的基础工具. 小潘, 我们出发!
没学数据分析我们都能知道, 数据分析的一般流程是 明确问题, 数据获取, 数据整理, 数据探索, 分析结果和数据展示. 当然数据分析的核心价值还有最后一步, 就是基于分析结果的预测模型.
明确问题
问题已经很清楚了, 我们想要知道的就是经过这一个夏天, 拜仁慕尼黑到底还剩下多少德国球员?
数据获取
显然我们需要一份拜仁慕尼黑的最新阵容, 经过搜索, 我决定使用百度百科的数据:
号码 姓名 协会 位置 生日 合同期限 身高/cm 1 曼努埃尔·诺伊尔 德国 门将 1986.03.27 2024.06.30 193 2 达约·于帕梅卡诺 法国/几内亚比绍 后卫 1998.10.27 2026.06.30 186 4 马泰斯·德利赫特 荷兰 后卫 1999.08.12 2027.06.30 189 5 邦雅曼·帕瓦尔 法国 后卫 1996.03.28 2024.06.30 186 6 约书亚·基米希 德国 中场 1995.02.08 2025.06.30 176 7 塞尔日·格纳布里 德国/科特迪瓦 中场 1995.07.14 2026.06.30 175 8 莱昂·戈列茨卡 德国 中场 1995.02.06 2026.06.30 189 10 勒鲁瓦·萨内 德国/法国 中场 1996.01.11 2025.06.30 184 11 金斯利·科曼 法国/瓜德罗普 前锋 1996.06.13 2027.06.30 178 13 埃里克·马克西姆·舒波-莫廷 喀麦隆/德国 前锋 1989.03.23 2023.06.30 191 14 保罗·万纳 德国/奥地利 中场 2005.12.23 2027.06.30 185 17 萨迪奥·马内 塞内加尔 前锋 1992.04.10 2025.06.30 175 18 马塞尔·萨比策 奥地利 中场 1994.03.17 2025.06.30 177 19 阿方索·戴维斯 加拿大/利比里亚 后卫 2000.11.02 2025.06.30 181 20 布纳·萨尔 塞内加尔/法国 后卫 1992.01.31 2024.06.30 177 21 卢卡斯·埃尔南德斯 法国/西班牙 后卫 1996.02.14 2024.06.30 182 25 托马斯·穆勒 德国 前锋 1989.09.13 2024.06.30 186 26 斯文·乌尔赖希 德国 门将 1988.08.03 2022.06.30 192 28 加布里埃尔·维多维奇 克罗地亚/德国 中场 2003.12.01 2025.06.30 180 32 约书亚·齐尔克泽 荷兰/尼日利亚 前锋 2001.05.22 2023.06.30 193 35 约翰内斯·申克 德国 门将 2003.01.13 2024.06.30 191 38 赖安·赫拉芬贝尔赫 荷兰/苏里南 中场 2002.05.16 2027.06.30 190 39 马蒂斯·特尔 法国 前锋 2005.04.27 2027.06.30 183 40 努赛尔·马兹拉维 摩洛哥/荷兰 后卫 1997.11.14 2026.06.30 183 42 贾马尔·穆夏拉 德国/英格兰 中场 2003.02.26 2026.06.30 183 44 约瑟普·斯坦尼西奇 克罗地亚/德国 后卫 2000.04.20 2025.06.30 186 数据整理
应该说这份数据是非常清楚的, 几乎不需要什么数据清洗, 唯一的问题在于球员所属协会, 有些球员是双国籍, 比如我厂青训格纳布里就是德国和科特迪瓦双国籍, 但是他其实是为德国队出战的, 所以我们需要把格纳布里的所属协会改成德国. 同样的情况, 我们需要把所有双国籍的球员的协会改成此球员效力的国家队.
好, 下面就开始数据获取和数据整理. 我们使用JupyterLab来完成:
首先, 导入需要的包
1 | import pandas as pd |
Pandas用来进行数据分析, Numpy是Python最棒的数学包, 主要是处理数据用. matplotlib 主要是用来画图
下面开始导入数据. 我在导入数据时发现一个问题, 就是如果让Python直接读拜仁慕内黑百度百科的页面, 就会报错, 错的一塌糊涂. 后来只好把网页保存到了本地, 再读取就正常了.
1 | tables = pd.read_html('examples/BayerMunich.html') |
这里我得说, 这Pandas从网页里抓表格的能力太NB了, 比之前我写爬虫用的BeautifulSoup简单的多得多, 直接tables[0] 就能把页面里的第一张表, 也就是拜仁阵容表给抓出来, 而BeautifulSoup还得靠抓取HTML标记, 看来以后做羞羞哒事情简单多了呢…
现在拜仁慕尼黑就以Numpy的DataFrame格式保存好了:
号码 | 姓名 | 协会 | 位置 | 生日 | 合同期限 | 身高/cm | |
---|---|---|---|---|---|---|---|
0 | 1 | 曼努埃尔·诺伊尔 | 德国 | 门将 | 1986.03.27 | 2024.06.30 | 193 |
1 | 2 | 达约·于帕梅卡诺 | 法国/几内亚比绍 | 后卫 | 1998.10.27 | 2026.06.30 | 186 |
2 | 4 | 马泰斯·德利赫特 | 荷兰 | 后卫 | 1999.08.12 | 2027.06.30 | 189 |
3 | 5 | 邦雅曼·帕瓦尔 | 法国 | 后卫 | 1996.03.28 | 2024.06.30 | 186 |
4 | 6 | 约书亚·基米希 | 德国 | 中场 | 1995.02.08 | 2025.06.30 | 176 |
5 | 7 | 塞尔日·格纳布里 | 德国/科特迪瓦 | 中场 | 1995.07.14 | 2026.06.30 | 175 |
6 | 8 | 莱昂·戈列茨卡 | 德国 | 中场 | 1995.02.06 | 2026.06.30 | 189 |
7 | 10 | 勒鲁瓦·萨内 | 德国/法国 | 中场 | 1996.01.11 | 2025.06.30 | 184 |
8 | 11 | 金斯利·科曼 | 法国/瓜德罗普 | 前锋 | 1996.06.13 | 2027.06.30 | 178 |
9 | 13 | 埃里克·马克西姆·舒波-莫廷 | 喀麦隆/德国 | 前锋 | 1989.03.23 | 2023.06.30 | 191 |
10 | 14 | 保罗·万纳 | 德国/奥地利 | 中场 | 2005.12.23 | 2027.06.30 | 185 |
11 | 17 | 萨迪奥·马内 | 塞内加尔 | 前锋 | 1992.04.10 | 2025.06.30 | 175 |
12 | 18 | 马塞尔·萨比策 | 奥地利 | 中场 | 1994.03.17 | 2025.06.30 | 177 |
13 | 19 | 阿方索·戴维斯 | 加拿大/利比里亚 | 后卫 | 2000.11.02 | 2025.06.30 | 181 |
14 | 20 | 布纳·萨尔 | 塞内加尔/法国 | 后卫 | 1992.01.31 | 2024.06.30 | 177 |
15 | 21 | 卢卡斯·埃尔南德斯 | 法国/西班牙 | 后卫 | 1996.02.14 | 2024.06.30 | 182 |
16 | 25 | 托马斯·穆勒 | 德国 | 前锋 | 1989.09.13 | 2024.06.30 | 186 |
17 | 26 | 斯文·乌尔赖希 | 德国 | 门将 | 1988.08.03 | 2022.06.30 | 192 |
18 | 28 | 加布里埃尔·维多维奇 | 克罗地亚/德国 | 中场 | 2003.12.01 | 2025.06.30 | 180 |
19 | 32 | 约书亚·齐尔克泽 | 荷兰/尼日利亚 | 前锋 | 2001.05.22 | 2023.06.30 | 193 |
20 | 35 | 约翰内斯·申克 | 德国 | 门将 | 2003.01.13 | 2024.06.30 | 191 |
21 | 38 | 赖安·赫拉芬贝尔赫 | 荷兰/苏里南 | 中场 | 2002.05.16 | 2027.06.30 | 190 |
22 | 39 | 马蒂斯·特尔 | 法国 | 前锋 | 2005.04.27 | 2027.06.30 | 183 |
23 | 40 | 努赛尔·马兹拉维 | 摩洛哥/荷兰 | 后卫 | 1997.11.14 | 2026.06.30 | 183 |
24 | 42 | 贾马尔·穆夏拉 | 德国/英格兰 | 中场 | 2003.02.26 | 2026.06.30 | 183 |
25 | 44 | 约瑟普·斯坦尼西奇 | 克罗地亚/德国 | 后卫 | 2000.04.20 | 2025.06.30 | 186 |
Numpy很贴心的把索引也加上了, 我们可以一眼看出, 拜仁慕内黑一线队目前有26名球员.
下面开始数据整理. 我们首先把双国籍球员给找出来:
1 | bayermunich[bayermunich['协会'].str.contains('/')] |
号码 | 姓名 | 协会 | 位置 | 生日 | 合同期限 | 身高/cm | |
---|---|---|---|---|---|---|---|
1 | 2 | 达约·于帕梅卡诺 | 法国/几内亚比绍 | 后卫 | 1998.10.27 | 2026.06.30 | 186 |
5 | 7 | 塞尔日·格纳布里 | 德国/科特迪瓦 | 中场 | 1995.07.14 | 2026.06.30 | 175 |
7 | 10 | 勒鲁瓦·萨内 | 德国/法国 | 中场 | 1996.01.11 | 2025.06.30 | 184 |
8 | 11 | 金斯利·科曼 | 法国/瓜德罗普 | 前锋 | 1996.06.13 | 2027.06.30 | 178 |
9 | 13 | 埃里克·马克西姆·舒波-莫廷 | 喀麦隆/德国 | 前锋 | 1989.03.23 | 2023.06.30 | 191 |
10 | 14 | 保罗·万纳 | 德国/奥地利 | 中场 | 2005.12.23 | 2027.06.30 | 185 |
13 | 19 | 阿方索·戴维斯 | 加拿大/利比里亚 | 后卫 | 2000.11.02 | 2025.06.30 | 181 |
14 | 20 | 布纳·萨尔 | 塞内加尔/法国 | 后卫 | 1992.01.31 | 2024.06.30 | 177 |
15 | 21 | 卢卡斯·埃尔南德斯 | 法国/西班牙 | 后卫 | 1996.02.14 | 2024.06.30 | 182 |
18 | 28 | 加布里埃尔·维多维奇 | 克罗地亚/德国 | 中场 | 2003.12.01 | 2025.06.30 | 180 |
19 | 32 | 约书亚·齐尔克泽 | 荷兰/尼日利亚 | 前锋 | 2001.05.22 | 2023.06.30 | 193 |
21 | 38 | 赖安·赫拉芬贝尔赫 | 荷兰/苏里南 | 中场 | 2002.05.16 | 2027.06.30 | 190 |
23 | 40 | 努赛尔·马兹拉维 | 摩洛哥/荷兰 | 后卫 | 1997.11.14 | 2026.06.30 | 183 |
24 | 42 | 贾马尔·穆夏拉 | 德国/英格兰 | 中场 | 2003.02.26 | 2026.06.30 | 183 |
25 | 44 | 约瑟普·斯坦尼西奇 | 克罗地亚/德国 | 后卫 | 2000.04.20 | 2025.06.30 | 186 |
1 | bayermunich[bayermunich['协会'].str.contains('/')].count() |
会看到有15人拥有双国籍:
1 | 号码 15 |
下面我们就得开始处理这些双国籍了. 拜仁慕内黑百度百科的页面确实做得很好, 凡是标注双国籍的, 编写者会把他效力的国家写在前面, 比如舒波莫廷, 喀麦隆德国双国籍, 但是他为喀麦隆效力. 但是由于编写者没有明确说这样的规则, 本着严谨的态度, 我还是挨个搜索并确定了每位双国籍的球员效力的国家队, 于是就有了这样一个对照表:
1 | nation_convertor = { |
如果有明确规则说/前面的是此球员的效力国家队, 那么只需要用正则表达式就能处理了, 当然了, 正则表达式我不会…
下面就可以开始替换协会里双国籍的情况了:
1 | bayermunich = bayermunich.replace(nation_convertor.keys(), nation_convertor.values()) |
结果是
号码 | 姓名 | 协会 | 位置 | 生日 | 合同期限 | 身高/cm | |
---|---|---|---|---|---|---|---|
0 | 1 | 曼努埃尔·诺伊尔 | 德国 | 门将 | 1986.03.27 | 2024.06.30 | 193 |
1 | 2 | 达约·于帕梅卡诺 | 法国 | 后卫 | 1998.10.27 | 2026.06.30 | 186 |
2 | 4 | 马泰斯·德利赫特 | 荷兰 | 后卫 | 1999.08.12 | 2027.06.30 | 189 |
3 | 5 | 邦雅曼·帕瓦尔 | 法国 | 后卫 | 1996.03.28 | 2024.06.30 | 186 |
4 | 6 | 约书亚·基米希 | 德国 | 中场 | 1995.02.08 | 2025.06.30 | 176 |
5 | 7 | 塞尔日·格纳布里 | 德国 | 中场 | 1995.07.14 | 2026.06.30 | 175 |
6 | 8 | 莱昂·戈列茨卡 | 德国 | 中场 | 1995.02.06 | 2026.06.30 | 189 |
7 | 10 | 勒鲁瓦·萨内 | 德国 | 中场 | 1996.01.11 | 2025.06.30 | 184 |
8 | 11 | 金斯利·科曼 | 法国 | 前锋 | 1996.06.13 | 2027.06.30 | 178 |
9 | 13 | 埃里克·马克西姆·舒波-莫廷 | 喀麦隆 | 前锋 | 1989.03.23 | 2023.06.30 | 191 |
10 | 14 | 保罗·万纳 | 德国 | 中场 | 2005.12.23 | 2027.06.30 | 185 |
11 | 17 | 萨迪奥·马内 | 塞内加尔 | 前锋 | 1992.04.10 | 2025.06.30 | 175 |
12 | 18 | 马塞尔·萨比策 | 奥地利 | 中场 | 1994.03.17 | 2025.06.30 | 177 |
13 | 19 | 阿方索·戴维斯 | 加拿大 | 后卫 | 2000.11.02 | 2025.06.30 | 181 |
14 | 20 | 布纳·萨尔 | 塞内加尔 | 后卫 | 1992.01.31 | 2024.06.30 | 177 |
15 | 21 | 卢卡斯·埃尔南德斯 | 法国 | 后卫 | 1996.02.14 | 2024.06.30 | 182 |
16 | 25 | 托马斯·穆勒 | 德国 | 前锋 | 1989.09.13 | 2024.06.30 | 186 |
17 | 26 | 斯文·乌尔赖希 | 德国 | 门将 | 1988.08.03 | 2022.06.30 | 192 |
18 | 28 | 加布里埃尔·维多维奇 | 克罗地亚 | 中场 | 2003.12.01 | 2025.06.30 | 180 |
19 | 32 | 约书亚·齐尔克泽 | 荷兰 | 前锋 | 2001.05.22 | 2023.06.30 | 193 |
20 | 35 | 约翰内斯·申克 | 德国 | 门将 | 2003.01.13 | 2024.06.30 | 191 |
21 | 38 | 赖安·赫拉芬贝尔赫 | 荷兰 | 中场 | 2002.05.16 | 2027.06.30 | 190 |
22 | 39 | 马蒂斯·特尔 | 法国 | 前锋 | 2005.04.27 | 2027.06.30 | 183 |
23 | 40 | 努赛尔·马兹拉维 | 摩洛哥 | 后卫 | 1997.11.14 | 2026.06.30 | 183 |
24 | 42 | 贾马尔·穆夏拉 | 德国 | 中场 | 2003.02.26 | 2026.06.30 | 183 |
25 | 44 | 约瑟普·斯坦尼西奇 | 克罗地亚 | 后卫 | 2000.04.20 | 2025.06.30 | 186 |
好了, 数据到此为止就处理完毕了. 这应该是数据清洗里最简单的情况了.
下面, 我们看看拜仁慕尼黑还有多少德国球员:
1 | bayermunich[bayermunich['协会']=='德国'] |
号码 | 姓名 | 协会 | 位置 | 生日 | 合同期限 | 身高/cm | |
---|---|---|---|---|---|---|---|
0 | 1 | 曼努埃尔·诺伊尔 | 德国 | 门将 | 1986.03.27 | 2024.06.30 | 193 |
4 | 6 | 约书亚·基米希 | 德国 | 中场 | 1995.02.08 | 2025.06.30 | 176 |
5 | 7 | 塞尔日·格纳布里 | 德国 | 中场 | 1995.07.14 | 2026.06.30 | 175 |
6 | 8 | 莱昂·戈列茨卡 | 德国 | 中场 | 1995.02.06 | 2026.06.30 | 189 |
7 | 10 | 勒鲁瓦·萨内 | 德国 | 中场 | 1996.01.11 | 2025.06.30 | 184 |
10 | 14 | 保罗·万纳 | 德国 | 中场 | 2005.12.23 | 2027.06.30 | 185 |
16 | 25 | 托马斯·穆勒 | 德国 | 前锋 | 1989.09.13 | 2024.06.30 | 186 |
17 | 26 | 斯文·乌尔赖希 | 德国 | 门将 | 1988.08.03 | 2022.06.30 | 192 |
20 | 35 | 约翰内斯·申克 | 德国 | 门将 | 2003.01.13 | 2024.06.30 | 191 |
24 | 42 | 贾马尔·穆夏拉 | 德国 | 中场 | 2003.02.26 | 2026.06.30 | 183 |
1 | bayermunich_nation = bayermunich.groupby(['协会']).count().sort_values('号码') |
号码 | 姓名 | 位置 | 生日 | 合同期限 | 身高/cm | |
---|---|---|---|---|---|---|
协会 | ||||||
加拿大 | 1 | 1 | 1 | 1 | 1 | 1 |
喀麦隆 | 1 | 1 | 1 | 1 | 1 | 1 |
奥地利 | 1 | 1 | 1 | 1 | 1 | 1 |
摩洛哥 | 1 | 1 | 1 | 1 | 1 | 1 |
克罗地亚 | 2 | 2 | 2 | 2 | 2 | 2 |
塞内加尔 | 2 | 2 | 2 | 2 | 2 | 2 |
荷兰 | 3 | 3 | 3 | 3 | 3 | 3 |
法国 | 5 | 5 | 5 | 5 | 5 | 5 |
德国 | 10 | 10 | 10 | 10 | 10 | 10 |
结果出来了, 拜仁慕内黑 26名一线队球员, 有10名德国本土球员, 在五大联赛里应该就算本土球员不少的了. 而这里诺伊尔, 基米希, 格纳布里, 穆勒应该都是国家队绝对主力, 格列茨卡应该是重要替换球员, 穆夏拉则是绝对的希望之星, 至于萨内, 一言难尽, 一言难尽.
最后就是数据展示, 这也是Python-Pandas-matplotlib的强项:
1 | plt.figure(figsize=(10,10)) |
求索集 - 八 今天联想发布了一个好东西
2022-06-21求索集 - 八 今天联想发布了一个好东西
这个世界上有些人, 比如我, 以大为美. 大的, 代表着更高, 更快, 更强. 在电脑的选择上也是如此, 更大的体量, 意味着更强的扩展能力, 更棒的散热空间, 从而带来更加出色的性能.
然而高昂的房价告诉我们, 钱是不多的, 空间是有限的. 有限的空间, 难道就是我们思维极限的桎梏? 难道我们就只能向现实低头?
不能够. 这个世界上总有一些追求突破极限的人, 他们总想挑战现实, 突破极限, 比如, 有没有可能用最小的空间, 做出最强的电脑?
今天, 联想用这样一款产品的诞生, 宣告了超小空间和超强性能, 可以在一起.
它的名字是:
联想ThinkStation P360 Ulta
ThinkStation P360 Ultra是一款全新的塔式工作站, 是联想工程师从0构建的全新产品系列. 虽然仅仅只有不到4L的体积 (精确地说, 3.9L, 2瓶大可乐), 但联想的工程师还是用自己的才智让这款产品的性能没有任何妥协, 哪怕是面对那些20L机箱的中端产品.
提供高达125W 12代Intel酷睿处理器的支持, ThinkStation P360 Ultra 提供了完整的12代桌面级处理器供选择. 128GB 最大内存, 且提供ECC选择, 这几乎能满足所有桌面端的高负荷工作. 至于工作站另一个看重的领域, 显卡, 联想提供了移动版的NVIDIA RTX A5000 显卡, 对于一款3.9L的产品, 这几乎已经是极致的选择. 当然在我看来, 如果能额外提供同级别的Gaming 显卡, 比如GeForce 3060, 那么可能会吸引更多的非专业客户. 同时, 多达8个显示器的支持也让这个小家伙似乎能做一些不一样的事情.
存储部分, ThinkStation P360 Ultra 也尽力了. 2个 M.2 PCIe Gen 4 插槽, 支持最大8TB容量, 也提供对磁盘阵列的支持. 2个以太网口, 对于我这样对无线网络的稳定性始终持怀疑态度的人而言是个好消息, 更何况这两个口里, 有一个是2.5G的. 对于当前全球都处于疫情威胁的情况下, 双有线网口和较高性能显卡的存在也为远程办公提供了更多保障.
其它值得一提的是前置双雷电4接口. 不少厂商都喜欢在这里降低成本, 它们会很聪明地用全功能USB-C代替. 这方面联想并没有做的太”精明”.
坦白说, 虽然这款产品对我而言很有吸引力, 小,强悍, 就像越野车届娇小身材却能翻山越岭, 迷倒无数老爷们儿的铃木吉姆尼一样,
能看得出联想工程师们对于从零开始创造一个全新的产品是多么执着, 但显然这并不是一款面向所有人的产品. 价格, 渠道, 知名度, 都是这款产品要面对的问题. 好消息是, 比起靠抄袭+粗制滥造+政策扶持+爱国营销生存, ThinkStation P360 Ultra的出现从另一条道路证明了中国也能制造出不错的产品, 只要我们肯动脑, 肯用心.
温格自传 - 3 - 开场白(3)
2022-06-18温格自传 - 4 - 开场白(3)
说好要翻译<<温格自传>>, 结果只搞了三期就搁置起来, 不知不觉已经半年多了. 对我而言开始一件看起来不怎么好玩儿的事并不容易, 所以还是想尝试继续, 既然我是个喜新厌旧的人, 那么半途而废这种做的够不够的事情, 似乎也可以先不做了.
)
在这些年, 足球经历了众多意义深远的变革, 而这其中, 一些变化我认为是超乎寻常的惊人: 越来越多的国家的球员参与到这项运动;
谈论足球的社交媒体不断涌现, 它们越来越成为必须品, 但也不断越界; 在期望前所未有的高涨时, 持续不断的来自运动员和教练的彼此隔阂带来的压力. 足球已经改变了很多, 无论是赛前还是赛后, 尤其是越来越多的关于比赛的分析数据被引入. 但是有一件事从未改变: 90分钟始终属于我们的球员, 这90分钟, 他们才是真正的国王.
欧洲足球被那几家大俱乐部掌控的日子一去不返, 越来越多的球队正在接近甚至达到这些大俱乐部的水准.
分析者已经成为一个重要的角色, 他们从比赛开始就被引入, 他们让更好的理解比赛成为可能, 他们用尽可能客观的标准去分析比赛, 而不同于以前所有事情都要依赖于教练的主观判断. 尽管如此, 教练依然是唯一做出决定的那个人.
这次翻译遇到的一个难点是
the emergence of social media with its demands and excesses
这句话我实在没明白, 但结合几个重要的单词, 我的理解和猜测是教授对于社交媒体的出现持一种谨慎乐观的态度. 他接纳社交媒体参与到足球中, 他也愿意自己和阿森纳去参与到社交媒体当中, 但是他对于社交媒体在足球中出现的利弊是持谨慎态度的, 所以我翻译成了
谈论足球的社交媒体不断涌现, 它们越来越成为必须品, 但也不断越界
也许是对教授相对了解一点, 所以遇到不太明白的句子难免会用我的主观理解去尝试翻译. 也因此, 这种充斥着主观观点的自传, 就成为了属于我自己的专属版本, 就像三国, 西游记, 其实我们看到的版本很多已经掺杂了修订者的主观意识. 也挺好玩的.
求索集 第七 - 也许这就是人生的真相 初识随机漫步有感
2022-06-05求索集 第七 - 也许这就是人生的真相 初识随机漫步有感
端午节, 数据分析开始学习随机漫步. 仅仅接触到一个变量的变化趋势就堪称无穷, 头晕脑胀不明所以, 我突然想起了屈原老爷子的诗句:
朝发轫于苍梧兮,夕余至乎县圃。欲少留此灵琐兮,日忽忽其将暮。吾令羲和弭节兮,望崦嵫而勿迫。路曼曼其修远兮,吾将上下而求索。
这里有几个名词我专门查了一下:
苍梧, 广西地名;
县圃, 昆仑山顶, 神仙居所
灵琐, 神仙住宅的大门
羲和, 太阳女神, 传说中最早的天文学家和历法制定者, 我国去年发射的第一颗探日卫星就是”羲和号”. 关于羲和, 需要注意的大概有两点, 第一, 她虽然好成女神, 但在神话里她是东夷族的族人, 换句话说, 就像神农氏, 轩辕氏, 有巢氏, 燧人氏一样, 虽然好成神, 但中国自古就讲究天人合一, 从不认为世界是神创造的, 只不过神是人的杰出代表罢了. 第二点, 羲和有个孩子,就是在中国文化中象征着太阳的金乌, 或者说是只三足乌鸦. 如今, 乌鸦在国内的地位一落千丈, 不知什么时候被安了个老鸹的别名成了霉运的象征, 反而隔壁日本倒是继承了金乌的形象, 还给起了个名字叫八咫鸟, 成了自己的神鸟. 甚至日本足协直接把金乌放到了自己的标志里, 算是和日本的太阳旗彼此呼应, 只能说, 我们在传承传统文化的道路上, 还有很多事情要做, 远不是吃两根前门楼子造型的冰棍就够了:
弭节, 停车休息
崦嵫, 山名, 甘肃境内
所以屈原老爷子仅仅用了这几句诗, 就展示怹无穷的想象力, 伟大的志向, 尤其是对真理的向往. 而初步知道了随机漫步的概念, 我第一反应就是, 难道这就是宇宙的真相?
1 | import random |
我定义了一个变量positions, 它会随着时间变化而随机变化. 它的变化逻辑是:
每个step, 都会按50%概率让这个变量随机增加3或减少3, 然后这样的随机变化执行10000次, 然后生成变量的变化图像.
我分别运行了5次代码,得到了5个完全不同的结果:
可以看到, 同样的代码, 最简单的一个变量的随机漫步, 5次结果完全不同. 有的一路走低, 有的先抑后扬, 但总体来说都是大起大落. 注意一下竖轴, 每次同样概率的+3 或 -3, 但有的区间瞬间就一路跌入低谷, 最小值直接到了-300多; 也有的区间意气风发, 昂首挺胸瞬间就到了+200多.
这样的图形可以附会到很多场景, 比如股市, 比如人生. 我想, 就算是真的有神灵, 就算他真的能写出一个人人生的代码, 他也无法决定这个人人生的走向, 因为在每个step, 人都会做出自己的决定, 这个决定是神灵无法预料的. 唯一能决定是哪种决定的, 只能是人自己.
我命由我不由天
这句话虽然是一个反派喊出来的, 但不可否认, 这个结论是符合逻辑的. 每个人的初始条件不同, 这是客观存在的, 但它只能决定你在每个路口做出决定后的变化幅度, 有的人变一次是 100, 有的人只能是10, 有的人是0.1. 但是我们却能决定, 这100 / 10 / 0.1, 到底是+, 还是-. 只要坚持, 只要努力, 只要做你觉得对的事情, 我想你的人生曲线会和你的期望大致相符.
<<国际歌>>里有一句话特别好地说出了我的心声:
从来就没有什么救世主
也不靠神仙皇帝
要创造人类的幸福
全靠我们自己
嗯, 唱着国际歌学习Python数据分析, 效果真好
求索集第六: 写公众号文章再升级 - 本地部署墨滴
2022-05-22求索集第六: 写公众号文章再升级 - 本地部署墨滴
自从学习了Markdown和hexo, 写Blog就变得更加有趣. 和hexo对Markdown的出色支持不同, 微信公众号有自己的一套格式系统, 对markdown的支持也不是很完美, 因此, 之前把文章导入到公众号的重要步骤就是用墨滴之类的第三方工具把markdown转换成公众号文章, 然后再发表. 概括一下, 整个工作流是:
使用typora编写markdown格式文章 - 在墨滴里对markdown文章进行重新编码和排版 - 发表到微信公众号
这里面存在的一个问题是, 墨滴作为一个出色markdown处理工具, 是基于线上的, 需要连接互联网, 而且数据也是存在墨滴的服务器上. 有时, 出于种种原因, 我们需要数据本地化. 针对本地化需求, 墨滴倒是提供了本地编辑器, 但是只有7天试用时间, 想长期使用就要按年付费. 实际上, 墨滴其实是开源的, 那么, 我们其实就有了自己搞一个本地版本墨滴的可能性.让我们研究一下.
首先, 我们先到墨滴的github仓库获取源代码:
墨滴 Github仓库, 可以看到, 墨滴使用JS开发的.
1 | Git clone https://github.com/mdnice/markdown-nice.git |
这一步相当于把墨滴的最新源代码下载到了本地.
其次, 编译墨滴源代码, 生成可以部署的墨滴程序代码
进入本地的墨滴源码文件夹, 因为是JS开发的, 百度了一下, 用npm 或 yarn就能对源代码打包:
1 | H:\learning\markdown-nice>yarn build |
打包完毕, 会在墨滴源代码文件夹里看到一个build文件夹, 这里面就是我们要的编译好的程序啦, 进去看看,
哦哦哦, 原来不是exe程序, 而是网页, 那就更棒了, 因为相对于程序, 网页形式的应用更加方便, 而且有本地网络访问的可能, 换句话说, 局域网里其它的电脑, 手机, 平板也能通过网页浏览器访问墨滴, 那岂不是我那联想平板也能写公众号文章了?
于是我选择打开index.html, 果然不行, 看来这个编译好的墨滴程序应该是需要网页服务器才能运行了.
然后, 把编译好的墨滴代码部署到本地IIS服务器
于是我开启了Windows Server自带的IIS服务器, 新建一个站点, 站点绑定好本机IP, 然后端口选了个1234 省的和其他应用冲突, 当然防火墙里也需要打开这个端口, 然后把build出来的墨滴代码全部拷贝到站点的文件夹下, 激动的时刻到了,
浏览器里输入
1 | http://192.168.0.107:1234/ |
哦也, 墨滴的界面就华丽丽的出现了, 注意, 这可是部署在本地的代码, 就算没有互联网也能运行的哟:)
然后打开平板, 同样输入本地墨滴的地址, 哦也, 这下平板也能愉快地用markdown写blog和公众号文章了, hoho~~~
求索集-第五-到底有多差? 标准差, 方差, 协方差学习笔记一
2022-05-15求索集-第五-到底有多差? 标准差, 方差, 协方差, 协方差矩阵学习笔记一
从页数看, Python数据分析已经学习到1/4, 进度却越来越慢, 原因很简单, 这本书主要面向已经有统计学或数据分析基础, 希望利用Python进行计算机高性能数据分析的用户, 而我基本就是个小白, 大学时学过的统计学, 线性代数, 数据分析也就还记得个转置和正态分布 (为什么没有萝莉分布???), 因此在学习时我必须话额外时间去了解这些基础概念. 但无可否认, 我已经深深喜欢上了这本教材, 比起之前接触过的<<XXX从入门到入土>>, 已经通俗易懂很多, 而且逻辑上也非常合理.
这段时间接触到了统计方面的几个基本概念, 标准差, 方差, 协方差. 坦白讲看见”差”我就虎躯一震, 尘封的那些不愉快的记忆, 不负责任的判断, 刻板的印象似乎慢慢浮现, 好在我本身脸皮够厚, 面对负面的情绪, 心境也慢慢从”你丫再说一遍试试”, “去你大爷的, 滚蛋”, 到”你随便吧”, 再到如今已经能去珍惜自己喜欢的声音, 不喜欢的则能产生漠视的本能, 无论如何, 还是坦然了许多.
跑题了.
不得不说, Python, 或者说基于Python的NumPy 数学库, 真的是太牛了, 很多复杂的计算仅仅用一条语句就能解决. 因此, 如果能以常用的NumPy函数为线索, 把涉及的统计概念能稍微深入了解一些, 同时对于简单的数据, 能进行纸笔计算, 那么这样学起来会更扎实和通透. 毕竟我现在不是为了升学或考证书而学习.
先说我对方差的理解. 对于一个问题, 我们在解决时会得到一系列观测值, 转换成数据就是一个一维数组, 那么方差就是这个数组中每个元素相对于均值的偏差程度的量化. 计算方法是:
μ是数组元素平均值, N是数组样本数 (也就是数组长度)
而标准差, 则是方差的平方根, 注意标准差分为标准差和样本标准差, 区别就是计算时前者的分母是N, 后者是N-1, 前者用于对全部样本进行计算, 而后者则是对巨量样本中选择的部分样本做计算.
方差是针对一组样本进行偏移分析, 而协方差则体现两组以上数据样本之间的一致性, 如, “男人财富的数量”和”其配偶的胸围”这两组变量是否存在相关性; 如果相关, 是正相关 (钱多胸大) 还是负相关 (只能说有钱男人品味真奇怪), 这个就要请出协方差来解决, 计算方法是:
cov (x, y) = E(x - Ex)(y-Ey)
而对于多组变量, 为了表示任意两组变量的协方差, 则需要协方差矩阵, 这也是最让我头大的地方. 这里必须仔细说说.
对于多组变量, 比如3组吧, 就像这样:
1 | X:1 3 7 8 11 |
那么很显然, 组合组之间存在3的平方, 共9种关系: XX, XY, XZ, YX, YY, YZ, ZX, ZY, ZZ.
那么, 把每种关系的协方差都求出来, 就知道了这9种关系的全部相关性, 如果把这9种相关性数值写成矩阵, 那么就是这样:
1 | Cxx Cxy Cxz |
这就相当于一个协方差元素表, 只要看每个值就能知道对应的两组变量之间的关系了. 而且我们还会有以下发现:
- 协方差矩阵从左上到右下的对角线就是每个变量的方差. 但注意这里的方差是样本方差, 分母是N-1, 因为NumPy计算协方差时分母就是N-1
- 由于cov(x, y) = cov (y, x), 所以这个表以从左上到右下的对角线为对称轴, 对角线两边的值是对称的
- N组数据的协方差矩阵是NxN, 所以一维或二维数组的协方差公式是”正方形”的二维数组
NumPy求解这些差本身的函数非常简单,
1 | arr4 = np.array([-1, 2, 5]) #定义一维数组 |
这部分内容肯定是层层深入的, 现在的初级理解肯定会迭代和更新. 今天最大的收获大概是, 这是我近年来为数不多能在周日花大段时间学习了. 看书, 查资料, 纸笔计算, 青春的感觉, 回来了呢~~~
寄花集-第五 我的妈呀
2022-05-08寄花集-第五 我的妈呀
今天是母亲节, 因此写下这篇关于母亲的文章
慈母手中线,游子身上衣。
临行密密缝,意恐迟迟归。
谁言寸草心,报得三春晖。
说到歌颂母亲的文学作品, 孟郊老先生的<<游子吟>>不得不提. 30个字, 就把母亲的形象以及孩子对母亲的感激之情表达的淋漓尽致. 现代中国人, 表达这种情感时, 则更倾向于一种更加简洁有力的方式:
我的妈呀
甭管男女老幼, 哪怕是一身腱子肉的糙老爷们儿, 遇到难题, 恐怕脑海里蹦出来的也是这句话. 而<<哆啦A梦>>里有一集也说的是类似的故事, 平时在家里不可一世的大雄爸爸, 遇到坐着时光机回来的大雄奶奶, 也是抱着自己老妈嗷嗷大哭, 因为我们都知道, 这个世界上, 还有一个人可以依靠.
遇到事情先想到母亲, 这并不是我们还没长大, 而是内心对母亲的依恋, 并不曾随着时间流逝而变化.
“马勺没有不碰锅沿的”. 夫妻难免因为琐事吵个嘴, 大家借机把心里的情绪宣泄出来, 未必就不是一件好事. 但是成熟的夫妻关系下, 大家都有个共识, 就是可以指责对方, 你骂我废物点心没能耐, 我说你不懂体贴不温柔, 都没事. 但无论如何千万别提及对方的母亲. 我想, 这里面的原因大概是在一个人的心中, 母亲的形象往往是完美的. 加上中国传统就讲究凡事不可提及父母的过失, 因此母亲在人们的心中往往已经成为了最纯真, 温暖的信仰, 支撑自己人生之路的擎天柱, 岂能容忍别人对自己的母亲指手画脚? 就算是白头偕老的伴侣, 最好也别轻易触及这个底线.
换个角度, 对另一半的母亲好, 说不定比对另一半好更能收到另一半的尊重和感激呢.
看古人的笔记小说, 经常出现的情节是, 老太太跟儿子闹变扭, 告到了县太爷那里, 县太爷往往连给儿子解释的机会都不给, 请老太太在大堂上一坐, 然后差役上来就把招老妈生气的儿子一顿揍, 然后还得按着脑袋给老太太磕头请罪. 实际上, 尽管中国古代的女性地位随着时间是在下降的, 而且很多时候母亲对于自己辛苦生下的孩子不见得就有母亲的名分, 但对于母亲的尊重和孝顺, 一直是中华民族传统. 汉朝有举孝廉, 就是选择孝顺的模范出来做官. 后世虽然没有明确要求, 但对于父母是否孝顺也是考核各级官员的一个隐形指标, 往往孝顺父母, 家庭关系和睦的人更容易得到提拔和重用. 这个其实很好理解, 咱们交朋友, 都喜欢交孝顺的, 对父母尚且忤逆无礼的人, 要么规劝, 要么敬而远之的好.
现在的母亲节, 源自美国, 是美国第二十八任总统威尔逊亲自签批通过的, 并且随着时间和美国的影响力推广到全世界. 我认为, 母亲节除了我们在这一天就要大张旗鼓轰轰烈烈地给母亲搞些活动让她们高兴; 静下心反思一下自己这段时间和父母相处时有何不妥之处, 哪些事做的不合适, 哪些话讲的不好听, 未来陪伴父母时再耐心一点, 细致一点, 也是一件挺有意义的事.
我的妈呀, 母亲节快乐 ~~~
求索集-第四-人人都是PM, 从写一封邮件说起
2022-05-05求索集-第四-人人都是PM, 从转发一封邮件说起
最近干活儿遇到不少问题, 一一解决并不为难, 但找到背后的根源, 从流程机制上找到避免方案又似乎挺麻烦, 而且看起来还得引入更多的人, 这ROI实在是低的可以, 所以只好先搁置起来做更主要的的事情. “不要在毛坯房里雕花”, 这话说得深得我心.
改革开放以来, 各种新型企业新型业务蓬勃发展, 其中称得上耳熟能详的工作, 非PM莫属. 翻开一个部门的架构图, 说不定你会看到满屏PM. 当然, 这里的PM既可能有Product Manager, 也可能有Project Manager, 但说到底, 都是一回事儿. 做Product, 您得通过Project做吧? 做Project, 您得搞出Product吧? 更何况, Project和Product都是Pro前缀, 有向前的意思. 做product做project, 都得向前看不是.
Project Product都是P, 论证完毕.
Product也好, Project也罢, 可大可小. 搞个登月project, 那是大的, 给同事写封邮件, 那是小的. 所以理论上, 我们每个人每每时每刻都在做project, 也都会产出product, 而且很多情况下, 其实不同人做的都是一个类型的project, 然后产出一个类型的product. 但同样的东西, 不同人做出来, 那也是千差万别, 三六九等. 今天, 我就想聊聊, 一个小小的project, 写邮件, 怎么能搞的好一点.
人人都是PM, 而写邮件也是个P, 论证完毕.
坦白说, 以前我是挺喜欢写邮件的. 打电话吧, 你接不接是这个问题, 接了以后愿不愿意听我讲是个问题,听我讲了你愿不愿意回答我是个问题,你回答我了我能不能听懂还是个问题. 不如我干脆把想说的事儿直接咔咔咔写出来, 然后发给你, 也不用担心你接不接, 反正有时间回复我就行呀; 也不用担心你愿不愿意听我讲, 反正我都写出来了; 也不担心你愿不愿意回答我, 反正大不了我再发个邮件催就是; 也不担心你的回答我看不懂, 反正现在翻译都基于AI了, 大概意思怎么也能猜个八九不离十.
好的, 邮件是工作中重要的沟通工具, 论证完毕.
我大概算了一下, 大概每天收到的邮件再几十封左右, 而这些邮件大概是这么个比例:
大约 50%是直接删了就行的;
大约 30%不需要马上看, 但需要存起来将来当个参考;
大约10% 很重要, 但不需要回复什么有价值的信息, 说个谢谢就行;
大约 10% 是真正需要回复的, 而且需要很认真的回复.
我大概每天写5-8封新邮件, 而不是回复人家的. 这些邮件中, 输出信息和要求人家向我输入信息的大约各占一半. 这是一件好事, 因为之前我要求人家向我输入信息的邮件占比在80%以上. 说明我已经从信息输入者慢慢向信息输入输出平衡者迈进, 好事.
写邮件, 第一种最常见的是转发. 说实话, 转发类邮件看起来没什么, 无非就是把Group A 讨论的结果原封不动发给Group B. 但其实这类邮件至今都是我最为头大的, 无论读还是写. 有时候收到同事转发的邮件, 哐当, 人家原封不动就把包含十几轮讨论的邮件给转过来了, 正文只有一句”以下是关于XXX的讨论, FYI / FYR” … 真的, 这是我心里大概奔腾的那个马恐怕不少于1000匹. 因为我连XXX这个概念是怎么回事都完全不知道. 最后, 我只能如此安慰自己:
我本来就不是这个信息的目标接收者, 人家发给我真的只是想让我FYI, 人家就是客气客气…
这种转发的结果, 可想而知. 不过还好, 目前没出现过”我已经发给你了, 你怎么会不知道? 你没看见邮件里XXX是怎么说的” 这样的指摘, 只能说同事人品好, 我运气还不差.
写转发类邮件, 看起来容易, 实则不一定. 原因很简单, 要把Group A的讨论结果发给B, 还要说清楚故事的背景, 而且很多时候讨论的过程也是有价值的, 那么转发这种邮件时, 如何怎么能把来龙去脉说清楚, 还要加上自己的想法, 对于患有”写作文浑身肚子疼综合征”二十多年的老病友而言, 简直就是煎熬.
所以这种邮件, 我比较喜欢这么分析:
- 这封邮件真的需要转发吗? 古龙先生说过”其实仔细想想, 这个世上并没有什么是非做不可的”. 我深以为然. 我们每天要面对的那么多问题, 要做的那么多事, 实际上能产生价值, 或者对核心目标有效的, 无非就是那么20%, 剩下的, 要么就是自己没想明白, 要么就是有必要的加戏. 所以说到底, 这封邮件, 真得有必要转发么? 你转发一封邮件的目的是什么?
初始发件人把给我的邮件发错了, 所以人家要转给我 -
- 好的, 这个理由足够OK, 这应该是转发邮件的第一理由, 没有争议.
这个信息对另一群人是有效的, 但这群人并未加入这次讨论
- 嗯, 听起来不错, 没有争议
展示自己的能力或者工作成果
- 等等吧.
这类邮件, 其实是最难处理的. 我哐哐哐干了半天, 然后悄么声就过去了, 不好, 不好, 尤其之前的邮件loop里居然没有领导, 也没有我的同事们, 这怎么得了? 难道我就甘心于在你们眼中我只是个插科打诨的家伙?
但正是这种心理, 反而往往会导致转发的邮件让人莫名其妙, 一头雾水. 这也正是很多时候最困扰我的一类转发邮件. 好消息是, 这类邮件我也没少发, 所以算下来不亏…
这就要进入我们的第二个思路,
这封邮件到底能给别人创造什么价值?
转个邮件不算什么, 大不了接收者嘿嘿一笑扔进垃圾堆. 但我们的功夫不就白费了? 所以这也是确定好要转发邮件后, 第二个要面对的, 就是, 转发这封邮件, 到底能为别人创造什么价值? 比如:
我提出了一个新思路 / 新方法
我发现了一个新问题
我提供了新的信息, 或者信息来源
我介绍了新的沟通渠道 / 创建了新的loop
我觉得, 如果以上都不符合, 仅仅是为了存在感, 我觉得还是省省吧, 除非您是领导或负责人. 有那个功夫, 多干点活儿少加会儿班岂不美哉?
第三步, 已经决定如何转发了, 那么怎么写这类邮件呢?
咱们先分析分析这类邮件的结构. 这类邮件显然就两个部分, 一个是篇幅最大的邮件主体, 里面是之前的邮件群聊记录, 一个是你输入的内容, 而且你输入的内容是在主体的上面.
那么很明显, 这类邮件, 我的理解有两种写法:
- 第一种, 如果你是想表达你自己的观点, 下面的邮件群聊仅仅是作为佐证, 那么最好的办法就是一开篇就抛出你的结论, 然后有必要的话介绍一下问题的背景, 对于转发的讨论过程中, 你认为最核心的内容, 最好是能直接截图放到你的邮件正文里, 就不要让大家自己再下面看了. 让大家把时间和精力集中在阅读您的精彩观点部分, 多么美好的事情~~~
- 第二种, 我想分享信息. 那么这里我比较倾向于把人家的信息要点总结出来, 这点其实我很欣赏这种<<一张图读懂XXX>>的形式, 把关键信息简明扼要的罗列出来, 千万不要让人家自己去下面长长的邮件讨论过程中去找.
第三种, 如果你仅仅想让大家了解讨论的过程, 了解你在讨论中的风采, 那么相信我, 我不想, 没人想. 所以这类邮件, 如果挖掘不出对别人有价值的信息, 那还是自己收藏起来的好
六
借由转发邮件这类事情, 其实我也一直希望做一件事情, 就是在每天闷头哐哐打字之余, 能有时间抬起头想想, 想想自己做了什么, 想想自己还要做什么. 我们每天都在做着大量的事情, 为他人提供各种大大小小的Product. 这些Product很多时候没有明确的好坏标准, 使用者也不一定回给你反馈, 那么, 如何经营好自己的Product, 如何经营好自己的Project, 我想, 这应该是经营好自己人生的一部分.
人生没有重来, 时光不可虚度, 为何不让我们更好玩儿一点呢, 是吧:)