0%

在家因为有了大屏显示器,所以Mac喜欢走主机模式,不使用屏幕。但注意到假如盒盖模式,Mac本身的mic是不可用的,扬声器还可以正常使用。如果想正常的使用mic,直接切换到耳机就行,但是如果不想使用耳机呢,那问题就来了,如何外接mic?

购买mic及耳机转接线

成本如下

  1. 阿斯泛(XFAN) D1 机顶麦克风 153RMB
  2. 绿联(UGREEN)耳机麦克风一分二转接线 21RMB

安装

注意

  • 以看到Mac正常识别外接mic为连接成功如上图
  • 要使用XFAN的相机连接线两阶线连接到UGREEN转接线的mic输入端
  • 虽然这里我没有连接耳机,但在Mac-声音-输入设备中也会看到外接耳机,忽视即可
  • 网上看到一些介绍说必须保证转接线的耳机也需要有接入才可以保证Mac正常检测到外接mic,经检测是不需要这样

桌面固定

因为我是用在桌面Mac上,所以需要固定下。

研究下了可以使用以下两个方案

  • 蓝丁胶解决
  • 迷你便携三脚架,1/4螺口即可

当前我采用方案1

写在最后

如上简单设置后

  • 在Mac盒盖情况下,可以使用Mac的内置喇叭+外接mic了,nice!
  • 当然你也可以单独使用外置的喇叭比如HomePod,灵活即可。

最近Team成员遇到一个问题,以为是TS编译方面的问题,并且还发我一个链接-flatMap is not a function #1822

当前这个问题很好解决,这个错明显是调用函数对象不是个数组造成的,但是他却断定是TS编译,暴露了对于TS的认识存在基础的误区。为了能够DRY的讲述这些基础认知,这里总结下。

TypeScript定位

Typed JavaScript at Any Scale.

上述是官网的Slogan,由此可以知道它只是类型化了的JavaScript,也就是Type + Script。也就是TS语言本身不对最终JS运行出现的各种兼容性负责。

TypeScript唯一且关键的武器-类型

JS本身很灵活,但是灵活就有代价,过多的自由也就带来了风险,不可维护性。TS的使用就像Java一样使得我们每一步的对象,函数都能有个明确的类型。当然TS比Java应该是更为灵活的,比如TS可以联合类型,工具类型等等。

你会注意到TS下支持any,unknown,一个是类型的上限,一个是类型的下限。但,请注意,如果整个程序里都是any,unkndown,到处ignore,你不如不用TS,因为都是任意,都是未知,那么谈何类型安全,所以注意这一点,也是红线。

TS在实际项目中的实践

TS在项目中,是作为开发语言的。利用TS的类型,在开发解决就尽可能的解决各种隐患BUG,不至于编译去掉了类型信息、打包、生产运行才发现问题。

推荐的工具链

  • Babel - 开发时或者打包时进行TS的转译
    • awsome-typescript等转译工具已不提倡,babel更为强大,对于比如JS的兼容性,可以利用babel的插件体系进行解决
  • ESLint - 开发时或者打包时对TS/JS进行代码风格检测
    • TSLint已经逐渐废弃,ESLint完全可以替代

TS的版本选择

  • 原则上,越新越好,只是类型-开发语言。所以TS即使升级并不会带来任何的代码BUG。相反,新的版本可以确保类型安全做的更好
  • TS最终是要编译为JS,而JS是运行在浏览器或者Node环境下。所以对于JS的兼容性问题,更多是TS中对于JS的编译配置,及最终运行环境
  • 实际项目中,因为很多的vendor已经是TS code,至少包含了很多的TS类型定义,所以一定程度上会造成项目本身TS并不好升级。一种方式是确保版本尽可能接近,比如只是布丁版本号范围内的不同,一种是关闭了打包的类型检测这种方式不提倡,但要知道,可以使用,因为只是类型,所以不会造成BUG

写在最后

总而言之,对于TS,你只需要知道它只增加了类型,所以如果使用TS,就请尽一切可能的明确类型。

最近偷偷的跑到了大理,在保证工作顺利完成的同时,开启了欣赏大理、洱海的模式。

原本预期也只是欣赏美景,但因入住的客栈太过美好美妙,使得旅行中增添了很多美妙的元素,以至于,我自己临走的时候都暗下决心,下次来了还住这里

寥寥数字记录下这份美好及点赞下经营这家客栈的这些美好的人。

不是广告软文,单纯有感而发

美好的景色

  • 整个客栈到处充斥着丰富的植被,不得不称之为园艺艺术
  • 客栈的天台,可以一边看到巍峨的苍山,一边看到洱海,抬头还可以看到满天的繁星。在客栈居住的这几天,我几乎天天到天台,手机连接蓝牙音箱放着歌曲,同时欣赏这些美景。

美味的食物

  • 免费早餐,每天早上可以吃到地地道道的米线和面,当然还有我个人特别爱吃的玉米饼
  • 午餐采取的拼餐模式,30/位。大家坐在一起享受美食,聊聊天,有说有笑,倍感放松
  • 晚餐也是拼餐模式,当然也可以自己点一些大餐-烤肉之类的,价格也都是市场价,我自己因为想去古城吃饭,所以并没有选择这个

热爱生活的经营者

如果不是本身就热爱生活,客栈是不可能做到这种程度的,这是我在体会中的认识,同时在跟经营者聊天时,也印证了这点。

比如:

  • 客栈的植被都是“大舅经营者之一”,持续打点
  • 客栈小到床单被罩,大到装修风格等等都是花了很多心思,确保本身游客或者他们自己居住舒服
  • 就餐的大米也是精挑细选的,本身不是吃货的我,也已经喜欢上了这种米,为此冲到了厨房,查看了品牌,最终在万能的淘宝中找到了

可爱的小动物

这家客栈除了这些有爱的经营者们还有很多小动物,短期的接触竟然神奇的使我不再惧怕猫了。当然我最爱的还是狗-尤其是客栈的这只边牧-茉莉。

写在最后

  • 临走时,我告诉老板,整个住下来,真的是高于预期。究其原因,一定程度是因为airbnb无法表现出这些细节,比如人文的美,同时本身客栈也缺乏一些宣传
  • 居住的这段时间,看见这些经营者,热情接待每位客人的同时,日常喝茶,弹吉他,撸猫,撸狗等等。艳羡同时。感叹一声,这才是生活。
  • 此文就当是帮这家店做一点宣传吧,因为它确实如此的美好。

惬意的一段旅行工作,花了点时间读了点闲书,其中就有这一本《高效能人士的七个习惯》。对于这七个习惯个人有自己的一点反思与想法。

Mark的同时,鼓励自己不断改进调整。

积极主动

我想自己至少在学习方面还算是主动,回忆最近的一年比较觉得有所收获的是

  1. 阅读,尤其是英文阅读的提升,其结果就是英文阅读上越来越小。
  2. 沟通,咨询,性格使然,我应该不属于闭塞的人,所以很多时候喜欢去聊,去交流,去提问,去分享。

所以,这个习惯我想还是做的比较好的,但是仍然需要继续进步。

要事第一

反思自己这一点,只能说是在进步ing,但还做的不够好。

比如工作中,很多时候,自己好说话,或者自己本身比较贪婪就会出现什么都想做,什么都想做好,但是其结果往往是都是半成品,或者一事无成,没有达到自己的预期。

比如生活中,问题相对不那么凸显,但是也存在类似的问题。其结果就是诸事都没有做好,进而也不会获取成就感,收获。

以终为始

这个习惯就是在说不忘初心。这点我想我做的还不错,并且这个认识我一直就有。我想码农更多时候是个社畜,因为只是拿钱写代码,为钱写代码,并没有什么愉悦感。但如果热爱就不同了,钱只是顺带的获得,但更多的是热爱。

我也是个程序员,但我的出发点是热爱,时至今日也是热爱,我是热爱编程而编程,我希望程序去解决实际的问题,解决他人或者自己的一点点需求,这就是我的初心,并且也不会改变。

双赢思维

这个习惯,我想我做的还不错,因为很多时候我并没有觉得个人的利益跟他人是冲突的,很多时候可以共赢。

最近的工作中对于这点多少也有自己的一点感触,如果你总是将自己跟别人搞成对立面,实际上你也可能会输,哪怕只是输了个关系。但是如果你能考虑自己利益的同时,站在对方的视角同样看待他人的利益,那么你最终行动及最终的收获,将会不止限于你自己,大家都会有所得。

知彼解已

这个习惯的本质是倾听,确实,多听听别的想法,实际上很多时候也会解决自己的一点困惑。

这点我想我做的也还不够,尤其最近1年有点闭塞了,需要做的是去多倾听,多交流。

统合综效

统合综效习惯带来的好处就是1+1>2。是啊,比如我当前所做的工作,面临的人,面临需要的沟通,有时别人如何能够好好的配合,就会非常的简单,但是有些人就是全然不顾大局利益,只盯着自己眼前的那点利益,其解决,全局利益损失,并且自己的那点利益也很危险。

但是换个角度,如果可以团结,那么大家都高效,都做到了1,有何不可,不好呢。

不断更新

是啊,谁也不是完全都对的,因此更多时候是调教自己,所有的习惯也需要不断的更迭,或者习惯背后具体的方法论。只有不断的更新才可以确保自己一直相对的优秀,那么面对不断变化的外部环境,也就可以更为从容。

写在最后

  • 寥寥数笔,即在读完这本书之后的一点感觉。

最近工作内容有一部分是在与SQL打交道,还是遇到了点坑,这里mark下。

背景

当前系统,面对数十万的数据表进行复杂update操作会出现问题,最终采用一条条的更新方式解决

程序源码

办法见源码

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
/**
* @description
*
* 1. SQL查出目标数据主键,导出CSV
* 2. 创建单条update SQL模版
* 3. 执行该JS文件,会生成目标SQL
* 4. 目标机器执行SQL
*
* 注意:修改CHUNK_SIZE来控制逐条更新的记录量
*/
const csv = require('csv-parser');
const fs = require('fs');
const ids = [];
const CHUNK_SIZE = 10;
// 输入数据文件
const INPUT_FILE = 'quote_ids.csv';
// 目标生成SQL文件
const OUTPUT_FILE = 'repair_data.sql';
const createSQLTemplate = (idArr) => `update \`a-prod\`.quote a left join \`b-prod\`.geographic_unit b
on a.sales_org = b.sales_org and a.sales_office = b.sales_office and a.business_unit = b.business_unit and
a.country = b.country_iso_code
set a.geographic_unit_id=b.id
where a.id in ('${idArr.join('\',\'')}');\n\n\n`;
fs.createReadStream(INPUT_FILE)
.pipe(csv())
.on('data', (row) => {
ids.push(row.id);
})
.on('end', () => {
const chunkIds = ids.reduce((res, item, index) => {
let group = Math.floor(index / CHUNK_SIZE);
if (res[group] === undefined) {
res[group] = [];
}
res[group].push(item);
return res;
}, []);

fs.writeFile(OUTPUT_FILE, chunkIds.map(item => createSQLTemplate(item)).join(''), () => {
console.log('write success');
});
});

按照如上的方式即可避免一次性更新造成MySQL程序

思考

  • 当前面临的单表数据也无非20万,数据并不多,但是即使查询有时候也很慢,原因是有些字段比较大,比如是text,而查假如询需要展示这个字段就很慢,经验就是按需所取,这也就是为什么不提倡使用通配符*,当然查询如果再join几张表也会降低查询效率
  • 对于update操作,强烈要求增加where条件,否则影响范围太大,除非你很确定必须那么做
  • 生产如果出现大规模要更新数据,一方面其实我认为暴露了程序BUG,毕竟这种需求场景都不该存在,另一方面如果更新很麻烦,也暴露了表是否design的不合理呢