無標題文檔

入手小新 Pro13 的 AMD Ryzen7 版本

经常背着 Macbook Pro 15 寸的笔记本上下班,这台笔记本完成了很多生产力的事情,但有其实并不是很需要那么好的算力的笔记本,所以轻薄的需求就提上了议程。

想着很多年没有用 Windows 10 了,想想换换口味再买台 Windows 10 的笔记本。考虑了很多相关的笔记本,例如 Dell 的 XPS、联想的 X1 Carbon(我对 Thindpad 的情节比较重)、甚至微软自家的 Surface Laptop。

这些笔记本都是非常好的选择,但对于我个人而言或多或少的有些都有些不满意的地方。例如 Dell 国行的 XPS 要高配才有 4K 屏幕,其他的都是 1080p;国行的联想机子那兼职就是劫贫济富,买行货的性价比非常的低;微软的 Surface Laptop 3 虽然硬件方面支持有限的升级了(升级硬盘),从 Win10 的笔记本平台来说没法升级硬件是个非常大的痛点。

偶然个机会看到有人在推荐联想小新的 Pro13 笔记本,其实对这个笔记本的第一印象是装黑苹果比比较合适,甚至可以说换了苹果兼容的无线网卡和蓝牙以后,几乎可以说是台完美的黑苹果笔记本

2020 款的小新 Pro 13 的 AMD 版本换上了低压版本的 4600U 和 4800U,京东的差价大概在五百上下,预售的价格分别是 4599 和 4999,这个价格就可以买到 8 核心 16 线程、512G NVME 的 SSD 以及 16g 内存、2.5K 屏幕的轻薄本,瞬间就显得非常得有性价比了。

由于是预售的缘故,所以被京东套路了下,6.1 首先需要支付 200 的定金,等到 6.10 再支付尾款。后来等我去支付尾款的时候,发现这款笔记本其实手速快的话可以直接购买,估计是支付了定金以后有不想买的客户,但心里的确因为等待了那么多天,多多少少有点不舒服的。

到手以后简单看了下做工还是不错的,至少从感官上没有觉得有什么粗糙和暗病的地方。这里唯一的不爽的就是由于 AMD 版本的机身是暗灰色的,但是底部的螺丝还是银白色因此显得非常的突兀。

键盘的手感完全对不起五千块钱笔记本的价格定位,对比 MacBook Pro 老款的蝴蝶键盘简直可以说从矮子里面挑矬子,所以如果使用惯了其他键盘的话,对这块的期望不要太高。

屏幕方面由于亮度对比 Macbook Pro 稍低一点,感觉屏幕的反光还是比较严重的,目前正在考虑要不要贴个磨砂的屏幕贴膜(可能不是个很好的主意)。

其实个人到手就将这个笔记本的硬件做了个升级,首先,将原机的无线网卡和蓝牙升级到了 Intel AX200 的 Wifi6 网卡,可以说这是 100 块钱的预算最值得升级的硬件。

考虑到一步到位的情况,同时京东 618 打折得过分而且加上三期免息,入了快西数的 SN750 1T(我的这台原机也是西数的,不过是 SN730 512gb 版本,可以说也很良心了),直接装上装系统一切正常。

任务管理器

最后,看下 Windows 10 任务管理器的样子,个人目前将这个笔记本作为轻度办公以及文档相关的工作,就这个而言硬件方面肯定是过剩的。但从性价比的角度而言,五千的预算就这个价位的配置的笔记本而言,几乎可以说找不到竞争对手了。AMD,Yes!

- eof -

万物之中,希望至美

这篇文章是有读者发我邮件,基于我的回复整理了下,散漫之处望谅解。原文如下:

Mail

凮凨你好,见字如面,诚惶诚恐。

其实有点惭愧,我个人已经有一段时间没有专职从事前端了,看老哥想和我了解前端的发展路线,我也只能从我过往的经历和浅见聊聊我对于这块的愚见。

我和兄弟的年纪差不多,稍长几岁。在我们这个年纪家庭和生活的负担不少,能够重新在专业路线上思变,说明兄弟也是很有想法和对自己负责的人。

但是按照我个人的从业经历来说,前端这个职位是属于相对入门容易,但也是很容易碰到「天花板」的职业。

对比和我同期一起从业前端的伙伴,经历了十多年的职业发展,很多有可能都已经不在前端这个行业,有些往前去做产品而也有些和我一样,更偏后端和架构。

这个就要聊到广度和深度的问题。曾经有一段时间,我负责团队招聘是带有非常强烈的个人品好的,尤其当简历看到「培训班」的经历,往往是会被减分的。

但这不是因为什么「歧视」的事情,而是因为在我印象中经历过「培训班」更看中的是操作层面的技术熟练度,而不是对于技术本身的追根溯源。

所以往往有这样子经历的从业者,会在技术的深度上浮于表面。看兄弟还有外包的经历,我更担心您对于技术深度方面的理解会不够深入,需要更加的注意。

很巧,前几天和玉伯聊技术的时候,我个人也聊到从行业上理解。我理解前后端这块的分工会更加不断的细分,会造成前端对于后端的理解也恐怕会出现两极的分化。封装和调用的便利性会造成忽略对于底层实现原理和概念,无形中会让前端更加无法接触技术的底层实现和理解。

同时看到兄弟的学历,是实话起点上来说对于目前的行业要求是相对比较落后,但是从同龄人角度上我理解这样子情况的原因,因此对于这块没有必要对于这块过于的焦虑。

学历和能力

这里搬出来张图,供兄弟参考。学历和能力不是正相关的,甚至可以说通过从业的经历以及对于自身认知的边界突破,往往这块的差距会被不断的拉伸和推平。

这几年,自媒体的发展让造成很多水平差次不齐的从业人员进来,为了眼球和流量贩卖焦虑。

互联网行业仍然是高速发展的行业所以和其他行业一样,30 岁的设计师、35 岁的程序员、40 岁的产品经理绝对不是「见光死」的年纪。

年龄只是代表了自己的经历和过往,这块对于所有人而言是最公平的。按照国人平均年纪 75、从业平均 40 年来算,我们经历过的 10 年职业路线,只是其中的几分之几而已。

有些就业单位对于年龄和学历的筛选会设立门槛,但是相信真实看中个人能力的公司,往往是发展向上的公司,例如在阿里也有很多 P7 甚至 P8 都是专科学历。

至于考虑去公司还是小公司,这往往是带有个人的品好的。

从我个人的从业经历来说,大公司不要求技术的全面要求单点技术的深入,是因为分工变细弱化了人在项目中的影响。而小公司因为资源的制约不可避免个人对总体项目的影响会更大些,所以往往综合能力比大公司的员工稍全面些。

这块兄弟可以根据自己的发展路线多加考虑,选择合适自己的路线。

最后,再聊聊技术人员的综合能力方面的理解。这块从我经历的很多技术管理人员来说,是普遍比较忽略的,网易这边称之为「软性素质」。

但哪怕是阿里和网易这样的平台,无论从技术面试还是职级晋升,对于这块的考核和评价往往技术侧能够给的评价和建议给到个人的意见和建议是不多的。

所以个人建议,除了技术方面对于广度和深度方面的加强,随着我们从业年限的增加,对于「软性素质」例如沟通能力、管理能力、协调能力等各个方面,都可以尝试着锻炼和提升。

「万物之中,希望至美,而至美之物,永不凋零」,三十而立的年龄是充满未来和机遇的年纪,希望共勉。

家里的内网开发环境(概述)

家里的开发环境越来越复杂了,所以需要复盘和回顾下目前的情况。这个得先从头开始说起:

Stage 1

Stage 1

应该说很上古的时期,和大部分开始的需求一样,需要离线跑些脚本。那时候我简单选用了台树莓派跑 NPM 的些代码。在很长的一段时期内它能很好的满足需求,因为只需要跑些爬虫和通知性质的脚本。

Stage 2

Stage 2

随着任务的增加,树莓派的性能瓶颈越发的明显,因为 NPM 的项目基本上都是些零散的小文件,tf 卡在 4k 的读取方面性能非常的弱。这时候开始考虑使用台「正儿八经」的 x86 小机子用来跑繁重的任务,技术栈这块也切换到了 Golang 以及 Python,而树莓派则退居二线作为通知和监控使用。

再后来数据量越来越「庞大」,达到了几百个 G 的级别,M93P 的硬盘容量明显不够了(SSD 256G、机械硬盘 1T)。加上对于数据安全性方面的考虑,购买了两块 2T 的硬盘以及 USB 的磁盘阵列盒子。

Stage 3

Stage 3

随着数据量的增加,我很快发现数据这块有了冷热的区别。同时,部署的环境也越来越复杂,虽然使用 Docker 搭配 docker─compose 也能很好的完成集成和部署,但在各个应用之间来回的切换 docker─compose 的目录让人感到非常的头痛和麻烦。

所以这时候在操作系统层面加上了 KVM 虚拟机这层,然后再再虚拟机上面跑 Docker。本来考虑上 K8S,但是其实各个应用之间是相对独立的关系,因此还是以单独虚拟机为单位分类各个应用的类别。

Stage 4

Stage 4

不过数据还是在不断的增加,我考虑到 USB 的磁盘阵列盒虽然能够满足目前的需求,但是横向的扩展性以及应用和数据分离做得还不够彻底,因此将数据这块单独部署了台 NAS 去处理

组装这台 NAS 其实走了很多弯路,硬件方面一开始用的是台盘位的 PC 机箱,但是很快发现非常不合适放在家里,一来机箱的体积太大了二来功耗也非常的大但是只能最多安装两到三块的硬盘。

和很多「垃圾佬」一样考虑过星际蜗牛的主机,四盘位的机箱加上 J1900 的四核低功耗的处理器,很适合用来做网络存储。但是还是考虑到数据的重要性,还是选择了单独的四盘位的机箱以及性能相对好点的 AMD 集成主板作为平台使用。

存储的选型方面一开始使用 CentOS + 阵列卡的形式,后面切换到了 FreeBSD + 直通卡配合 ZFS 的方式,各有优劣和千秋这里不展开详细的说明。

Stage 5

Stage 5

于是乎硬件和虚拟机的节点越来越多,怎么去治理和监控就成了纠结的事情了。还有因为国内网络环境的问题,所以我在网络这块考虑使用了 N1 作为旁路由和透明网关作为国际网络加速。原先的树莓派也替换为 N1 同时部署了 Grafana 以及 Prometheus 作为节点的监控和报警

服务发现这块选用了 Consul 和 DNSmasq 汇聚,这样子每个节点启动自举的时候,就可以在内网环境拿到对应的域名而不用去找 IP 地址,很方便。

Stage 6

Stage 6

基础环境搭建好了以后,逐渐的装了 Syncthing、Gitea、Drone 等用于数据同步以及测试代码的托管和 CI。由于测试数据的量逐渐的收敛了下来,所以很多时候 Runner 在空闲的状态,但随时可以调用很方便了。

硬件方面主要是有些补足的设备,例如我后面又购置了台瘦客户机装了 FreeBSD 用来实时给 macOS 做时间胶囊备份使用。

同时,买了两台 UPS 以及写了些对应的脚本,用于在断电的时候主动关机。

@TODO

@TODO

前几天从 @yff666 那边得到块星际蜗牛的「遗产」,组了台双盘位的 Raid1 小 NAS 主机,打算用来存冷数据,不过这块的数据需求还是要看目前的业务情况。

监控这块我觉得还有比较短板的地方,例如如果家里网络不通则无法收到通知邮件了,这里想考虑使用台 Android 手机配合 adb 发送短信,后面想好了再继续做吧。

- 待续 -

随忆 FreeBSD

Install FreeBSD

趁在隔离的空档期间组了台 NAS,自然而然的安装了 FreeBSD 和将数据拜托给了 ZFS。时间过得很快,回想接触这个系统已经有十几年的时间了。

初次接触 FreeBSD 还是在大学的时候,那时候自己的 MMX 166 笔记本装的还是 Slackware、实验室有台机子装的是 FreeBSD 4。由于次意外的断电,实验室的这台机器由于硬盘故障无法启动,当时作为兼职的运维只能我先去看看能不能解决。

那时候 FreeBSD 直观的印象其实很初步,就是配置方面和 Slackware 差不多,同时也体验到了 ports 的好处,就是至少不用像 Slackware 一样满世界的找 tar.gz 包了。

那时候「水云间」的 BSD 板块还是比较热闹的学术氛围浓厚,上面有各种各样的「奇迹淫巧」各种各样的 shell 脚本和配置文件。那时候的我们年轻而且还气盛,和争论 Vim、Emacs 哪个好一样,争论 GNU/Linux 和 BSD 之间孰优孰劣(现在是 Android 和 iOS 了吗?)也是个老生常谈的问题,热闹看得不亦乐乎。

再往后工作了以后就忙碌了很多,去「水云间」的日子也少了。在本世纪的头个十年,技术方面的发展非常的迅猛,「把玩」技术的时间也不会很多。我的主要系统也从 Slackware 往 Debian 上面迁移到后面买了台 Mac 就一直用 macOS 至今。

FreeBSD 的发展也是一路过来,版本从 4 一直到现在的 12,还是一路保持着 KISS(keep it simple, stupid)原则。当然FreeBSD 的「Simple」其实不是「简单」的意思,而是简洁。

安装好新的系统以及软件包以后,只需要拷贝应用的配置以及 /etc/rc.conf 还有 /boot/loader.conf 就可以直接投入使用。

开玩笑的说,这类的 BSD 系统是努力让管理员尽可能的快的遗忘掉它,因为知道使用 FreeBSD(以及 BSD 系列)的管理员,是知道拿它去做什么的。

所以这也是为什么眼看着份额却越来越低使用得人甚至讨论的人也是越来越少,而 FreeBSD 还存在的原因之一吧,哈哈。

的确 FreeBSD 从学院的背景走出来,很多地方不像 Linux 那么「分裂」以及「随意」,所以在 FreeBSD 安装盘里面有很多「年代感」的文件(所谓的传承?)。

FreeBSD 还是会时不时得给我些「小惊喜」。回到我的那台 NAS 上,我曾经需要给阵列卡加上监控和配置。LSI 厂商其实提供了 MegaRaid 等工具,在 FreeBSD 下其实官方已经提供了 mfiutil 这类的工具可以直接使用,同时参数和命令比 MegaRaid 更加的清晰。

FreeBSD 的在这个方面做得是两个极端,要么就是没有提供任何的支持,要么就是有非常完善的 Manual 以及 Handbook 说明。同理,对于 ZFS 方面的支持也是类似。除去协议方面的问题先不谈,我保守得至今还不敢在 Linux 生产环境下使用 ZFS,这已经是我的个固有的印象,而 FreeBSD 能做到开箱即用。

FreeBSD 的 slogan 现在变成了「The power to serve」。但 Linux 在应用层面 Docker 以及 K8S 等工具完全改变了传统运维的方式,这我在 FreeBSD 下是没有找到任何与之对比的杀手锏的(你问我 Jail?凑合吧…)。

在我看来,未来 FreeBSD 相对 Linux 应该更加下沉,无法让应用开发接触到了。它在底层存储、数据库、防火墙和网关还会继续占有一定的使用场景。对对,如果你说 macOS 甚至 Switch 也是 FreeBSD (或者和它有关系)的话。

FreeBSD 除了在特定场景下的优势,我个人对于 FreeBSD 的情感甚至可以说情怀,也是让我继续使用这个系统的原因。好比上面说的你十几年前的 rc.conf 不加修改扔到最新版本的 FreeBSD 还能兼容一样,当全部初始化时候出现 login 提示,这一切都给人感觉通过时间沉淀已经升华到另外一样东西了。

前几天,在之乎上看到个问题「现在使用 FreeBSD 是一种什么样的体验」、「现在学 FreeBSD 有必要吗」等等,只能轻轻的笑笑。其实,正式知道和使用 BSD 这些系统的人,基本上都是那些已经年过三十正在慢慢失去了折腾的时间和精力,或者已经在办公室里拿着保温杯泡着枸杞看着 KPI 担心脱发的那帮人了吧。

回想起如果那个下午没有意外的断电,可能就不会接触 FreeBSD 更不会有十几年的陪伴。但现在看过来,还是不后悔时间花在每次 /usr/ports 目录下等待 make install 完成屏幕暂停的时候吧。

因为,FreeBSD 以及 Slackware、Makefile、Vim… 等这些名词,毕竟是我的青春呀,笑(

- eof -

使用多个版本交叉编译 Golang 项目

在编写内部项目中,往往不同的项目因为历史遗留问题,会有存在多个版本的 golang 编译器共存的情况。

同时,由于 golang 的包管理的短板(虽然在 golang 1.11 以后推出了 go mod),因此不可避免的安装 govendorgo dep 等多个包管理工具,非常的混乱。

本地使用多个 golang 的编译器版本其实更容易造成混乱,同时 env 满天飞也非常不方面维护。解决这块的问题很容易就想到了使用 Docker 去编译和检查本地项目, Docker 官方维护了多个版本的 golang 镜像

那么考虑的目标是:

  1. 使用同一个 Makefile 以及 Dockerfile 去维护项目的编译
  2. 因为 golang 1.11 以后官方推出了 go mod,所以尽量使用官方的包管理工具
  3. 接上条,老版本的依赖和本地编译使用 go mod vendor 去管理
  4. Makefile 不管 golang 编译器的版本问题,编译器版本让 Dockerfile 去管理
  5. 本地环境尽量使用最新版本的 golang 编译器,然后导入到 vendor 中

那么这样子,我们可以简单的使用 Dockerfile 去编译执行,例如下面使用编译器版本 golang 1.9.7 类似:

FROM golang:1.9.7 AS builder
# ...
RUN go build .
# ...

但需要注意的是,golang 1.11 之前必须代码在 $GOPATH 中,所以需要映射

ENV GOPATH /go
ENV GOROOT /usr/local/go
ENV PACKAGE ${YOUR_PACKAGE_NAME}
ENV BUILD_DIR ${GOPATH}/src/${PACKAGE}

# ...
COPY . ${BUILD_DIR}

然后在本地使用 go mod vendor 下载依赖包到项目的 /vendor 就可以在老版本中免去使用 dep、govendor 等依赖工具,统一使用官方的 go mod 去管理和下载依赖。

还有需要关注的是 Makefile 需要加个判断,为了增加通用性,建议根据路径判断 golang 的环境路径,而不是判断是否在 Docker 环境下:

# ...
ifneq ("$(wildcard /go)","")
    GOPATH=/go
    GOROOT=/usr/local/go
endif

GO=env $(GO_ENV) $(GOROOT)/bin/go

# ...

build:$(DIR_SRC)/main.go
    @$(GO) build $(GO_FLAGS) -o $(BIN) $(DIR_SRC)

这样子 Makefile 文件就可以同时同于本地高版本的环境以及 Docker 编译环境了。

详细的示例代码可以参看 这个简单的项目(作用只是用于生成随机密码),其中的 Makefile 以及 Dockerfile

最后,有个讨论 vendor 目录到底要不要纳入到版本控制中?我个人的看法是看情况,大部分情况下不会将这些第三方代码纳入版本控制中。主要的理由有:

  1. 这些代码是第三方库的代码,不会直接更改以及维护;
  2. go.mod 以及 go.sum 文件已经保存了第三方依赖的库信息(版本、hash 等等);
  3. 库文件通常会很多,纳入这些的文件会「污染」本地的 git history;
  4. 不同于开源项目,我们本地的开发环境是可控的。

所以,类似的 Consul 等比较大型的项目还是会将 vendor 目录纳入到版本控制中,个人认为这也是因为兼容方面的考虑更多些,而如果个本地项目往往环境是可控的。

- eof -

我的照片

嗨!我叫「明城」,八零后、码农、宁波佬,现居杭州。除了这里,同时也欢迎您关注我的 GitHubTwitterInstagram 等。

这个 Blog 原先的名字叫 Gracecode.com 、现在叫 「無標題文檔」 。 要知道作为码农取名是件很难的事情,所以不想在取名这事情上太费心思。

作为八零后,自认为还仅存点点可能不怎么被理解的幽默感,以及对平淡生活的追求和向往。 为了避免不必要的麻烦,声明本站所输出的内容以及观点仅代表个人,不代表自己所服务公司或组织的任何立场。

如果您想联系我,可以发我邮件 `echo bWluZ2NoZW5nQG91dGxvb2suY29tCg== | base64 -d`

分类

搜索

文章