华为水墨屏平板 Matepad Paper 体验
背景 背景当然是 Kindle 退出中国了。 在此之前,移动阅读主要还是靠手机,为此去年换手机时还换了 Max 款。Kindle 主要拿来看 Kindle 商城有的书或者在 图灵 买的电子书。这两个地方加起来书其实还挺全的,奈何微信读书前几年实在太香了,很多书用体验卡就能读。所以一直想要一个能装微信读书的水墨屏设备。 恰好,最近文石又新出了一款小尺寸设备 Poke 4,立即加入购物车学习了一波,从 Poke4 看到 Poke3,再看到 Note 5+。文石的设备看了一圈,除了价格比同行贵一截,品控和售后口碑也不太行。在找另外的设备的时候就看到了 Remarkable 和华为的这款 Matepad Paper。两者价格差不多,Remarkable 主打手写体验,系统是 Linux,能装 KOReader 不能装微信读书。那么结论有了,买华为! 体验总结 结论 基本的阅读/笔记/手写体验已经能比较好的满足了。 因为个人使用场景限制,功能使用比较单一。 作为当前水墨屏设备硬件的天花板,硬件确实强。 网上测评普遍诟病的软件优化问题确实存在。 不是华为生态的话,体验会有缺失,但影响不大。 购买建议 买!不亏的!整体体验目前已经能保证了,硬件够强,剩下的等软件更新就行。 详细体验 我主要使用的是微信读书 APP,也会使用 KOReader 看自己导入的一些 PDF。偶尔也会用他的手写功能当笔记本用,记一些譬如会议纪要之类的东西,但整体使用不多。 微信读书 基本使用体验良好,翻书很快。划线标注的时候反应有点慢,并且微信读书里不能写笔记。可以用系统自带的全局标注或者分屏笔记功能补充。 因为官方没有针对微信读书做适配,偶尔会出现显示错误。这时候退出阅读界面重新选择书籍打开就会恢复正常。 显示效果: 分屏笔记效果: 显示错误的效果: KOReader Matepad Paper 的 CPU 是一款 ARM CPU,在 KOReader 的 Release 页面选择对应的 APK 下载并安装就好。 原始显示效果: 自动剪裁+提高一点对比度后效果: 续航 因为是 Android 平板,哪怕是水墨屏,待机也是会耗电的。连接 WIFI 的情况下,一晚上待机大概掉 6% 左右的电(没仔细算过,反正不到 10%) 以一天两到三个小时的阅读时间算,一天耗电大概 20%。在水墨屏设备里这个续航基本没法看,但也没有其他人说的那样不堪。不至于一两天一充。 华为生态 因为是鸿蒙系统,内置了华为云功能,和华为生态的集成是有保障的。 没有华为设备,没法验证。据传,稍后阅读功能没法离线。只能在线阅读。 非华为生态 作为苹果生态用户,当前系统缺失了一些设备间信息交互的能力,需要根据自己的习惯进行额外的配置。...
Terraform 综合指南
原文链接:https://blog.gruntwork.io/a-comprehensive-guide-to-terraform-b3d32832baca 从今天开始,我们会发布一系列的博客来介绍我们在实际场景中如何使用 Terraform 来定义和管理我们的“基础架构即代码”(infrastructure-as-code)。 如果你之前没有使用过 Terraform,Terraform 是一款开源工具,能够让你以一种简单、声明式的程序语言来定义你在多种云服务商(譬如,AWS,Azure,Google Cloud,Digital Ocean 等)上的基础架构并通过一些简单的命令行操作管理和部署他们。 在 Gruntwork,我们使用 Terraform 作为我们 基础架构即服务工具库 中的主要工具之一。该工具库收集了支持 AWS,GCP 的超过 300,000 行可复用、经过实践检验、具备商业支持的工业级代码并已经在数百家公司的线上环境使用。在这篇介绍文章中,我们将会讨论为什么我们认为每一家软件公司都需要实践基础架构即代码。在本系列剩下的文章中,我们也会涉及以下主题: 为什么我们使用 Terraform 而不是 Chef, Puppet, Ansible, SaltStack 或者 CloudFormation Terraform 介绍 如何管理 Terraform 状态 如何使用 Terraform Modules 创建可复用的基础架构 Terraform tips & tricks: 循环,if 语句和陷阱 像一个团队一样使用 Terraform 因此,让我们开始讨论为什么每一家软件公司都需要使用代码来定义他们的基础架构。 为什么使用代码定义基础架构? 很久很久以前,在一个很远很远的数据中心,一群被被称为系统管理员的强大人类手动部署系统架构。每一台服务器,每一条路由表配置,每一个数据库配置以及每一个负载均衡器都是由手工创建并维护。这是一个黑暗和充满恐惧的时代:害怕宕机,害怕突然搞错配置文件,害怕缓慢并脆弱的部署,同时也害怕系统管理员转向黑暗面时会发生的事(星战梗)。好消息是,感谢 DevOps 联盟的反叛,我们现在有了一个更好的方式来做这些事情:基础架构即代码(IAC)。 不同于在一个 Web UI 上点来点去,或者 SSH 到一台服务器上然后手动执行命令,IAC 背后的思想是写代码来定义、配置和管理你的基础架构。这带来一系列的好处: 你可以自动化你整个的配置和部署过程,让它变得比任何手动过程更快和更可靠。 你可以在源文件中展示你系统架构的状态,而不是让它保存在系统管理员的脑子中,这样所有人都可以阅读。 你可以使用版本管理工具管理那些文件。这意味着你的系统架构的完整变更历史都在提交记录里保存下来了。你可以使用这些记录来 debug,如果有需要,也可以随时回退到任何历史版本。 你可以通过 code review 和自动化测试验证你的每一个系统架构变更。 你可以创建(或直接 购买)一组可复用的、文档齐全的经过实践检验的系统架构代码来让你的系统架构更容易扩展和演进。 使用 IAC 的另一个非常重要且经常被忽略的原因是:它让开发者更开心。部署代码是一件重复和乏味的工作。机器可以快速和可靠地执行这些任务,但人做的很慢并容易出错。此外,开发者很容易对这类任务感到厌烦。因为这类工作没有创造力,没有挑战,也没有认同感。你可能在数个月内完美地部署代码,但没有人会注意到,直到你某一天搞砸了。...
年度更新2019
前言 自从说自己是年更博客之后,2019 年这一整年,真的就完全没有再更过。说到做到了! 以下是正文。 惯例的一年流水帐 这两年状态不太好。总结总是没什么东西写。一方面一不小心就写成了流水帐,一方面也确实很久没有正经写东西了。立了又立的“写作练习”计划也始终是印象笔记里的一篇篇只开了一点点头的草稿。前几天给博客换了个主题,还被朋友吐槽博客一篇写不满 800 字。吐槽非常准确,真是优秀的朋友啊! 言归正传,从最近说起好了。今年其实一直都想把博客写起来,没人看就当写作练习,练练文字表达能力。一不小心有几个人看就可以顺势搞一个微信公众号之类的放点小广告赚点零花钱。毕竟人到中年,副业成了刚需。 所以,就在前几天,为了今年的年度更新,也为了给开始写博客一个理由(其实是忘了 jekyll 的设置不想再看一遍),把博客换到了 hugo 并顺势换了一个主题。因为 hugo 不再是 Gihub 官方支持的生成器,顺势就把部署换到了 Netlify 。整体的体验还算 OK 。反正博客也没啥人看, Netlify 的免费额度够用一万年了。 再之前,折腾了一次工作,离职入职再离职。吐槽起来又是一个很长的故事。之前和朋友吐槽的时候就说,当时的代码或者和队友的聊天记录都是随手截一段就能开始吐槽半天。但另一方面也确实说明了自己确实是不够强。不管是业务能力还是软技能的沟通管理能力,都还有非常长的一段路要走,今年要继续加油了。 离职再入职再离职,说起来好像流程挺长的,但其实全程零间隔。甚至中间还抽空回家结了次婚。就在国庆假期,而且因为是黄历上全国热门的好日子,还和几个朋友结婚撞日子了,可以说非常的一次体验。身处十八线乡下农村,结婚的习俗其实挺有意思的。只是身处其中的话,就只感觉到莫名其妙的费钱费力。有一种花大价钱讨好各种父老乡亲,最终得到了婚礼耍猴表演中演猴子机会的感觉。也隐隐看到了一些回乡创业发家致富的机会。 年度 Flag 虽然很少提了,但年度 Flag 该立还是得立。如下: 过去一年读书比预期的少了不少,主要是读书时间更零散了。今年希望能改善一下,多读点书。 今年希望娱乐活动更多样化一点。多看看电影,把攒着的各种片子都掏出来看看。 人到中年,今年希望能正式把副业做起来,不求多少收入,希望能补贴一下各种软件和服务的订阅钱。 多出门走走。 好的,就这些了,大家明年见。
年度更新2018
作为一个年更博客的博主,年看着 2019 年已经过去三分之一了, 2018 年的更新终于还是来了。 自从 17 年折腾了一阵之后,18 年从经历来看并没有太多变动。依旧还在那家公司,也依旧在做手忙脚乱的救火队员。总的来说,在技术方面没什么长进,更多的是作为一名专业的软件开发人员的理解更深刻了。 新的一年,即使已经过去三分之一,也还是希望自己的工作,生活都更加顺利。希望队友们都加油。然后,玩得开心!
年度更新2017
眼看着 2017 年就要过去了,域名也已经续费了一年,但博客还没更新过。想想还是更新点什么,保持一年至少一更的进度好了。 今年是比较折腾的一年,从工作到生活,能折腾的基本都折腾了一遍。结果怎么样不好说,总之日子勉强还能过就是了。 稍微记录一下今年比较重要的事情: 换了份工作,新工作认识了一批很有趣的人,也学到了一些新知识。叫嚣了几年要学的前端也终于算入了个门,总算能差不太多的写点小页面了。 卖掉了笔记本,买了台式机。大约两个月前的事情。之所以重要,是因为之前从来没想过卖掉那台笔记本,毕竟是刚毕业那会儿省吃俭用攒出来的。然而租房子住,一套台式机 + 公司笔记本 + 自己笔记本 + 女朋友的各种设备,家里这些东西有点过剩了。而且台式机显卡和内存贵炸了,需要回点血。结果就是咸鱼同城卖掉了。过程还算顺利,希望那台笔记本在它的新主人那继续发光发热了。 买了些提升生活品质的东西。譬如,椅子、电动牙刷什么的。毕竟身体一直挺虚的,有几天脖子突然疼的动弹不得,隐约像是提前进入了中年期。于是开始注意这些小细节了。不奢求自己多强壮,还是想要健康一点。 重新开始记账。用的是复式记账软件 beancount , 纯文本的账单记录,外加 fava 提供的非常漂亮实用的 web 界面,可以清晰的知道自己有多少钱,自己的钱都在哪里,都花到什么地方去了。到目前为止,正好记了一个月,虽然该花还是照样花,但对于自己的钱去向有了一个清晰的了解后还是感到一丝莫名的心安。 总之,接下来一年继续努力了。
emacs上手指南
作为一名 emacs 始终学不会用户,其实已经用了差不多一年 VIM 了。最近不知道看到了啥,突然又想尝试一下 emacs 了。于是又找了本教程学习了一下。推荐一下看的书《mastering emacs》,面向纯新手,写的挺有趣的。 然后是正文,上手过程: 安装 emacs 启动 emacs 输入命令体验一下吧~ 咦?我的 meta 被 manico 覆盖了。退出 manico ?不能忍。C-x C-c 上手结束
从zsh迁移到fish了
自从知道 fish 之后,就一直很眼红 fish 的补全和高亮功能。 之前也有过一次短暂迁移的经历,配置好了基本的 fish 和 oh-my-fish 环境,然后就放弃了。。。 理由是,fish 不兼容 bash,现有的一些脚本没法用。而且用的 VIM 插件中有依赖 posix shell 的, 换了 fish 导致插件不可用(虽然当晚就找到解决方案并解决了。。。解决方案见文末。。。 记录一下这次迁移中遇到的一些状况好了。 首先,fish 要装 2.x 版(之前装的,怎么装忘了,大概就是 brew install 一下),oh-my-fish 直接上github 仓库复制、粘贴一下就好。 我用的主题是zish,挺好的! 然后就是插件的配置了。 我用到的插件有 brew git balias theme percol python autojump 说明 balias是 alias 的增强版,实现了 alias 命令的自动补全。 theme是浏览和变更主题 用的,方便随时看厌主题了换一个。 percol是查询命令行历史用的(就是其他 shell 都有的ctrl+r功能,原生是不带的。。。然后还要在命令行把percol装上)。 python提供了一些常用的 Python 快捷键(开一个临时 HTTP 服务什么的,暂时还没用上)。 autojump就是在 bash 版的 autojump 上包了一层。 为什么要用 autojump 而不是看起来更加厉害的z,是因为 z 在下列目录结构下的操作方式超出了我智商的上限,无能为力了。 path/hello path/hello/llo 因为两个目录拥有一样的前缀,所以前者权重始终大于后者,这个没有问题。 但是。。。...
博客又迁移了
今天突然想看一下自己的博客,结果发现 gitcafe 貌似把我的博客仓库搞坏了。。。先前折腾了半天,把博客源文件和 pelican 生成的 HTML 文件放到一个仓库的不同分支下了。今天上 gitcafe 一看,俩分支内容一样了,连历史都一样,而且没有收到任何异常的邮件,给坑的有点惨。于是干脆把博客搭到 github 上了,大厂毕竟相对可信一点。 根据之前的经验,pelican 其实挺原始的,很多东西做的不算完善,而且本地生成 html 再 push 到仓库的方式个人感觉也不是太好。Jekyll 这种直接推 markdown 文件的方式看起来感觉好多了。至于发布生效的那点时间,实在不是很 care。 总之,以后博客就以这个为主了。