View profile

恣意生长 by Hwang - Issue #3

恣意生长 by Hwang - Issue #3
By Hwang • Issue #3 • View online
恣意生长是一份自我观察的 Newsletter。如果不输出,那么输入会显得不那么有意义,自大地以为自己“无所不知”。所以做一份 Newsletter 似乎会是一个审视自己的好机会。这份 Newsletter 会为读者提供个人的关于视角/产品/设计/编程 四个方向内容的思考和感悟,他们会是杂糅而又恣意的。

引言
Hello,农历新年前的第三期内容奉上。
很开心TualatriX 图拉鼎 推荐了我这个仅仅更新了 2 期的 Newsletter,希望本期内容不会让大家失望。开始之前,我想先简单介绍一下对自己的 Newsletter 的想法,开始写这份 Newsletter 的目的是为了让自己日常碎片化的摄入能够有所产出,积累和沉淀自己,所以本身并没有太多刻意给自己定想要达到的目标(指订阅数之类),公开发布出来也是为了更好的激励自己,让自己能够坚持✊。不过,如果能够收获一些读者,实在是意外之喜。
  1. 这是一份更新不怎么频繁的邮件通讯,意味着收到这份邮件,时间可能已经过去一个月了(时间过得真是快呀)。因为工作原因,我并不会很频繁的更新我的 Newsletter,我希望能够至少做到 100 期。按目前的更新节奏,这可能是一个需要10年时间才能完成的超长目标。 一直以来我都觉得创造的过程都是伴随痛苦,我并不讨厌这份痛苦,不过即便再包含热情,也还是会因为担心自己的输出满足不了大家的期待而惴惴不安。
  2. 这是一份比较混杂的偏向互联网行业内容的邮件通讯。 因为是在一个较小的创业团队,每个人做的事情都比较杂,所以我摄入的内容也会比较多。所以这份邮件覆盖的内容会比较多,从我们的角度出发,这或许比较适合和我们一样想做小而美产品的人,或者是需要横向扩展知识面的人。作为开发者,你可以看看设计的趋势、内容,作为产品,你可以看看开发的一些细节,设计的一些理念,同样的作为设计师,你也可以了解一些产品和研发的事情。
  3. 混杂的内容意味着很多时候,我输出的内容要么太浅,要么太深。做任何一件事情,要做好都不容易。我并没有在产品/设计/编程的领域都齐头并进的做的那么好,也很难做到面面俱到的优秀。所以在面上的内容输出上,很多时候是会偏浅的。不过在实际工作中是需要切实的解决很多问题的,而这些问题很多时候是会偏尖深和专业的。这几方面的原因,就会造成这样参差的内容结果(我觉得这是这个 Newsletter 的特色了)。所以如果遇到自己习以为常的东西或者看不懂的东西,大家大可以带着看个热闹的心态。
  4. 内容庞杂,意味着出现错误在所难免,希望大家批评指正。 每一期内容都比较多,相关信息我都会尽量核验。不过即便如此,犯错也再所难免。如果出现错误,欢迎大家回信指正。邮件并不能更新内容,但是网页存档我会时常更新维护。
Cook 说了,苹果也是会犯错的,何况我呢😆
Cook 说了,苹果也是会犯错的,何况我呢😆
最后,我一直相信:
生而为人,应该能够换尿布、策划入侵、杀猪、开船、造房子、 写十四行诗、算账、建墙、正骨、抚慰临终之人、接受命令、 下达命令、合作、独行、解决方程式、分析新问题、 清理马粪、编程、烹饪美食、高效战斗、英勇牺牲。 
成为专业人士在职业发展上似乎是一条符合时代的选择,但是我认为多体验多感受才能获得更好的人生体验,那些在不经意间习得知识或是技能会更加丰沛自己,让自己不至于成为无聊的 Nerd 。如果能做好两件事,就不要只做一件事(另外,如果只能做好一件事,那把一件事做好即可)。
Ps. 就在写这个文章的时候,读到了「如何在某一领域成为世界顶尖 -#5」,成为专家,因为边际效益递减,并非完全是完全经济的决策😆。
视角 —— 交易费用
最近在产品沉思录中看到了这么一句话:
张一鸣曾说他的大部分决策基于科斯定理——在交易费用为零的情况下,不管权利如何进行初始配置,当事人之间的谈判都会导致资源配置的帕雷托最优。
张五常
张五常
我本科是经济学专业的,看到帕累托最优、科斯定理、交易费用这些名词还是非常亲切的。对我而言,经济学的启蒙其实就是来自张五常的《经济解释》,张五常和科斯都是制度经济学的重要奠基人,而交易费用的思想同样也指导这我的日常的决策判断,所以我很想和大家「安利」一下这个概念:
交易费用或是交易成本:指企业用于寻找交易对象、订立合同、执行交易、洽谈交易、监督交易等方面的费用与支出,主要由搜索成本、谈判成本、签约成本与监督成本构成。
这么说,可能还不够明晰,张五常的说法更加鲜明
  • 任何不会在一人经济(犹如鲁宾逊漂流记的状况)内出现的机会成本。由于一人经济内不可能构成社会,所以也没有制度和经济组织。张氏亦认为,交易费用就是制度费用(Institutional cost)。
  • 任何不牵涉直接生产的机会成本。但它并不一定牵涉到实质的交易,如隧道收费员的薪金,一方面包括了他提供收费服务的贡献,一方面包括了他提供管理及监管服务的贡献。另外,各种交易费用是不容易分开的。
例子:
  • 在一人世界内不可能有偷窃的行为。所以在社会中,任何防止偷窃所带来的机会成本都是交易费用。(如安装门锁、闭路电视等)
  • 在一人世界内不需要律师,所以在社会内,训练律师、聘请律师的费用都是交易费用。
张五常很会举这样通俗真切的例子,如果感兴趣可以看《经济解释》
张五常很会举这样通俗真切的例子,如果感兴趣可以看《经济解释》
回归日常生活,非常多的让人不快乐,降低幸福感的工作事务都与交易成本有关,比如,跨部门间的相互推诿,填报各种没有意义的表单,不停的开对接会议等等。很多时候,我们在做的这些事情就是所谓的交易成本。一人公司看起来很美好,其实就是因为一人公司很容易达成超低交易成本的情况,所以交易成本是一个很实际很切合生活的概念。
产品 —— 我在用 Obsidian 整理记录 / OdysseyDAO 的 Web3 教程
用 Obsidian 整理日长记录
我已经使用 Obsidian 三个多月了,不算长也不算短。在这段时间里,有一些使用感觉或者使用经验,我觉得可以拿出来聊聊。
第一印象
开始我认为 Obsidian 只是抄袭 Roam Research 提供的一个免费版本。并且编辑器长得和 VSCode 非常相似,十有八九是使用 VSCode 的 Monaco Editor 改的。再加上各种「教程」视频时常会以打造类似 Notion Database 的体验为标题,让我觉得是一个「蹩脚」的蹭 Roam 和 Notion 热度的产品,总结下来就是第一印象非常之差。
所以即便早早听闻,也并没有让我投入行动。不过后来因为偶然间刷到了这个视频,让我对 Obsidian 产生了兴趣:
DAILY NOTES
过去我时常会在 Todo 里面塞一些链接,同时还会把喜欢的图片、照片存到 Google Keep 上,这些东西都比较零碎,也不利于整理,所以我就规划着把一些日常零碎的东西都移到 Obsidian 上。
双向链接 + 随处生效的 Tag 功能让我在整理 Daily Notes 时并没有太大的负担。我使用 Daily notes 这款插件,并且固定设置了模板,主要有:
  • Todo: 记录代办,同时使用 Checklist,将轻量级的任务管理都迁移到这边。因为绝大多数的事情都已经在 Notion 里面了。
  • 技术探索🪛:如果写代码,我会把遇到的问题,Stackoverflow 的链接之类的事情都记录在下面。
  • 随机🧩:一些图片、链接都会放到这里。
  • 想法💡:自己想到的一些事情,我会放到这里。
这些记录的内容,基本上都会被我打上不一样的 tag,这样后续整理起来就会非常方便。
值得说一说
我最喜欢的插件:Sliding Panes,使用 Obsidian 最大原因就是 Sliding Panes,优雅好用。
ps. 小道消息显示,notion 很早就测试过这种展开文章的方式,不知道为什么一直没有发布。
ps. 小道消息显示,notion 很早就测试过这种展开文章的方式,不知道为什么一直没有发布。
我的文件目录:
  • article:自己写的文章内容,会一起整理到这边。
  • assets:默认的图片、附件存储位置,可以在 Obsidian 里面设置指定默认附件位置,这样直接贴图进来也不会把目录弄乱。
  • capture-article:值得收藏的文章。
  • keywords:所有「关键字」相关的文章都会放到这里。
  • notes:Daily Notes 存储的目录。
  • topic:一些自己关注的问题,可能是多个「关键字」组成的内容。
实质性的好处:开始写 Newsletter 之后,这份日常记录就更加有用了。
可以选择 Logseq 但是为什么没用?
  • Obsidian 插件生态相对更加完善一些;
  • Obsidian 相对更加灵活一些;
  • 以后 Logseq 做好了,同样是 md 文件,迁移也很方便;
OdysseyDAO 的 Web3 教程简单翻译
稍微整理了一下 OdysseyDAO 的 Web3 教程科普内容。内容真的很基础,属于扫盲性质的内容,看个大概即可。
原文地址:Intro to Web3
有一个玩笑:Web3 就是从「通过 Google 登录」变为 「通过 MetaMask登录」。
有一个玩笑:Web3 就是从「通过 Google 登录」变为 「通过 MetaMask登录」。
诚实的说,我对 Web3 并没有多么深的理解,但是很显然有一些粗浅的知识就能够发现「他们宣称的和他们所做的」很多时候并不是一件事。去中心化的 Web3 和安那其主义一样美好,我担心的是本应还在基础设施构建阶段的「去中心化」革命,搭上这波风潮过后,还会有自由的互联网吗?
扩展
其他产品内容
1.Notion themes:Notion 主题的 Chrome 插件,感受上会比 Notion enhance 侵入性小一些,当然也只能在浏览器中使用了。
2.Block Protocol:为 Block 提供互相可用的协议。
3.The Gray Area 的年终总结中看到了一段话,有些感触:
Every year I receive the barrage of newsletters titled “Year in Review”, but until this year I have never understood why. Why email dozens to thousands of people telling them about your achievements and failures? Well, because it feels nice. When you have things to be happy about and learnings to reflect on, you feel good talking about them. Like the social media dopamine release, but slower.
每年我都会收到一连串题为“年度回顾”的时事通讯。但直到今年,我才明白为什么。为什么要给成千上万的人发电子邮件,告诉他们你的成就和失败?嗯,因为这种感觉很好。当你有值得分享的快乐,有值得反思的问题时,通过谈论它们,会让自己感觉很好。这就像社交媒体上的多巴胺释放一样,但速度较慢。
如果你是个较年轻、处于职业生涯早期的员工,会在以下方面遇到困难:
  • 获得高质量的导师指导和职业指导
  • 与其他情况类似的年轻员工建立关系和社交基础
  • 独立的管理和平衡工作量
  • 打造一个职业身份(professional identity)
如果你是个有小家庭的员工,会在以下方面遇到困难:
  • 平衡工作和家庭责任(尤其是当学校或托儿所不可靠的情况下)
  • 在家办公时很难专心,经常被家事打断
  • 确保当孩子意外出现在视频会议背景中时,不会对职业发展产生负面影响
如果你是个经理,会在以下方面遇到困难:
  • 了解团队的每个成员的个人目标、意愿、挣扎和激励方式
  • 组织成效高的会议、工作计划和头脑风暴活动
  • 与其他经理建立跨职能的合作关系
  • 平衡不同时区的会议,通常是跨国会议
设计 —— 为设计师介绍一下 Storybook
自 Figma 诞生以来,设计师和开发的距离越来越近。组件(components)、AutoLayout、变体 (variants) 等等功能,在开发中也都有对应关系。
一个典型的前端项目
以国内常用的 Vue.js 项目为例,下图是一个简单项目的基本结构:
一个 Vue.js 的前端项目
一个 Vue.js 的前端项目
首先,常见的软件设计架构都会将「视图」和「数据」抽离出来(Vue 使用 MVVM 的模式,作为设计师不需要了解这么深入,除非你也想转前端😂 )。和设计高度相关的主要是 「视图」部分,上图中主要和视图相关目录
  • components:组件目录,用来存放不同的在项目中重复出现的组件。
  • view:用来组织功能页面,就是多个组件合并后的部分。大多数情况都是导航栏以外的部分,不过有时他也会是一个完整页面。
Model 与Variants
开发者在做视图时,首先需要做的就是定义这个视图的数据模型。下图是一个用来展示没有信息的空状态组件的代码:
仅 Javascript 部分
仅 Javascript 部分
这里面 props 下面的结构就是这个数据模型。例如
  • icon:图标
  • size:大小
  • text:文本信息
这就是一个基本的组件的结构。
对于设计师而言,Figma 中的一个图标可以在组件库中按住 command+option 拖拽进行替换。对于开发而言就是传入不同的 icon 名称进行替换。
我们可以这样理解,开发者的数据模型和设计师的变体(variants)关系:Variants 是一个视图的数据模型更新后最终状态。如果实现这个最终状态,开发者和设计师做的事情是截然不同的,所以这中间就会有设计想要这个效果,但是开发实现非常难或者可能根本无法实现的情况。其中很大部分原因就是这个视图的「数据模型」定义不能满足需求。
说了那么多,总算要进入主题,Storybook 了。
Storybook 是做什么的
Storybook 是一个面向前端开发的 UI 管理工具,在一些中大型项目中,一个项目的 components 目录的东西是很多开发人员一起做的。所以为了节省沟通交流成本,开发者可以把自己做好的组件放到 Storybook 中,将其中的「数据模型」直接展示出来,这样其他开发者只需要看有哪些 props ,就能明确这个组件能做出哪些「variants」(这么说并不完全正确,一个组件最终成什么样,props 只是控制其中一部分,这里只简单理解即可)。这样,在开发过程中就减少了看一些复杂的逻辑代码的过程,直接在 Storybook 提供的交互的页面上查看即可,开发者之间可以通过他了解之前的组件功能。
相信很多设计师可能也看过 Ant Design 或是 Element 的文档,其实 Storybook 对于开发来说就是可以相对简便的构建这样的文档。
对于设计师意味着什么
在前端领域,如今的UI 和 Develop 之间的间隙已经非常小了,而 Storybook 最近推出的功能,进一步拉近了两者的关系。
Storybook 推出了 独立的 Figma 插件,根据官网的表述,他能够提供以下的功能:
  • 🤝 Link design components to stories
  • 🕹 Play with interactive stories in Figma
  • 🎯 Compare implementation to the design
目前插件还在内测,暂未发布正式版。
对于 UI 设计师来说,Webflow 或是最近的 Framer 都只是相对静态页面的内容,现代的前端开发很多时候都是在做 Web App 的事情,所以更多场景还是在做「数据」相关的事情。对于没有工程师背景的设计师来说,这中间还是有很大的鸿沟。Figma 将部分工程上的抽象思想带到了设计师领域,而 Storybook 提供的功能将使得 UI 设计对于 「数据」操作能有更加直观的感受。
更加具体,UI 设计师通过插件,最基础的能够更好确认设计实现情况,将评审细化到组件乃至 Variant 级别。再则可以通过关联 Design 和 Stories (一个组件的文档在 Storybook 中称为 Stories ),UI 设计师能够一窥开发实现。最后,通过 Storybook 的 Figma 插件,UI 设计师 可以进一步了解 Storybook 本体,从而更加深入的理解开发实现上的事情。
对于产品经理来说,学会使用 Postman 是一个重要的技能,也许不久之后对于 UI 设计来说,学会使用 Storybook 也会同样重要。
当然现实地说,并不是每个团队都有意愿或是精力去做这些事情的。对于开发而言,维护 Storybook 其实也有负担的,对于设计师来说,可能做好设计再深入动效、3D 之类的会比了解开发更「经济」。做一个 Interdisciplinary 的人才还是做一个分工明确的 Professional 都是个人选择。
实效性不强的一些消息
  • 钉钉的设计规范
  • 单纯从设计和开发角度考虑,其实钉钉做的是不错的,例如较早的完善的支持了 Dark Mode、有 TouchBar 的支持等等。不过从产品角度考虑,钉钉是一款「自上而下」设计的产品。
  • 说回到这个规范:以往国内的开源设计规范都是以 Web 端为主,钉钉这份规范比较好的考虑到移动端与Web端的差异,所以比较推荐。
  • Framer 推出新产品:提供设计到部署的产品: 要开始和 Webflow竞争了。我一直觉得 Framer 的产品做的是不错的,一时瑜亮。可惜总让人感觉被 Figma 压一筹。有时候会想,即便 Framer 做的这么好了,也依然艰难求生存,创业可真是容易呀。
  • 数说 Anyway.FM 的2021JJ 真的是太会抢前端饭碗了哈哈哈哈。Anyway.FM 的 2021年,年终总结,使用滚动来动态加载数据。非常喜欢这样的东西。
  • JPEG XL、AVIF、WebP 2 · 次世代图片格式评测
AVIF 有损压缩效果最好,无损压缩非常糟糕。编码速度很慢。
JPEG XL 无损压缩效果最好,有损压缩较 AVIF 有些许差距。编码速度快。
WebP 2 无损压缩效果优秀,有损压缩的上限达到了 AVIF 的水平,但下限很低,不稳定。编码速度很慢。
最好的方案是把 AVIF 用在有损压缩,在照片、纹理、广告等场景使用。把 JPEG XL 用在无损压缩,在 UI 设计、存档等场景使用。
而我非常看好 JPEG XL ,虽然它的有损压缩不如 AVIF,但比起 JPEG 来说有了非常大的进步,而其无损压缩又有优势,并且在最大图像尺寸、色彩深度上有决定性的优势(在传统的摄影、印刷领域)。另外还是唯一可以无损转换旧有 JPEG 图片到新格式的格式,迁移旧数据不需要有所顾虑。只待浏览器支持度能赶上 AVIF 了。
编程 —— 浏览器 Server-Sent Events / CSS clip-path 绘制一个 200万的曲线
SSE: Server-Sent Events
一句话简述就是一个轻量级的 WebSockets。之前并不知道 SSE,偶然间看到,详细了解一下:
  • 严格地说,HTTP 协议 无法做到服务器主动推送信息。但是,有一种变通方法,就是服务器向客户端声明,接下来要发送的是流信息(streaming)。
  • 也就是说,发送的不是一次性的数据包,而是一个数据流,会连续不断地发送过来。这时,客户端不会关闭连接,会一直等着服务器发过来的新的数据流,视频播放就是这样的例子。本质上,这种通信就是以流信息的方式,完成一次用时很长的下载。
  • SSE 就是利用这种机制,使用流信息向浏览器推送信息。它基于 HTTP 协议,目前除了 IE/Edge,其他浏览器都支持。
  • 看一个技术,了解他的优劣势非常重要:
  • Advantages
  • Transported over simple HTTP instead of a custom protocol
  • Can be poly-filled with javascript to"backport"SSE to browsers that do not support it yet.
  • Built-in support for re-connection and event-id
  • No trouble with corporate firewalls doing packet inspection
  • Useful for apps that enable one-way communication of data, eg live stock prices
  • Potential stumbling blocks
  • SSE is limited to UTF-8, and does not support binary data.
  • SSE is subject to limitation with regards to the maximum number of open connections. This can be especially painful when opening various tabs as the limit is per browserand set to a very low number (6).
  • SSE is mono-directional
应用场景:
比较典型的就是 :
  • 实时股价的推送。
  • 新闻推送。
  • 日志监控。
因为性能限制,一些大场景还是需要使用 WebSockets。
参考资料:
这个和以前提到的基于HTTP的长连接PUSH是一个概念吧。还有1个像素的iframe长连接,就是会出现页面夹在进度条永远不结束的问题。老技术换了套新衣?
clip-path 绘制一个 200万的曲线
clip-path 是一个还有些兼容性问题的 CSS 属性,不过大部分「现代浏览器」的兼容性都还是不错的:
是不是有点精细了🌚,可以使用 CSS Doodle 的 @shape 快速完成:
相关文章与工具:
其他
  • replicache: 一个 react 生态的小巧的实时同步包。需要收费。
  • 官方 Demo:https://replidraw.vercel.app
  • Nmap: 是一个常用的端口扫描工具(我为什么会看到这个😯)。
  • ClojureScript 与 Datascript :听播客了解到技术,在新兴的笔记软件(就是指 Logseq 和 Roma)中有较好的应用。大概了解了一下,也是一种对 JavaScript 的优化语言。
  • Tarui:简单来说是一个 Rust 写的 Electron,slogan 是「Build smaller, faster, and more secure desktop applications with a web frontend」 有趣的是 1Password 是最大的赞助商之一。 
  • 额外说一下 Electron,Electron 的成功,很大程度是因为他对于前端开发非常非常友好,只要是一个「现代的前端工程师」,用 Electron 完全不存在阻碍,我们团队也在使用 Electron 做产品的开发。
  • 为什么选择 Electron
Hwang
1Password 8也用Electron 重写了。越来越多的新兴软件使用 Electron 做开发。尤其是工具类 APP ,无论是 spline、linear 、Tempo 等等都选择了 Electron,对于工具类 APP 来说,Electron 真的有很多优势,当你作为团队 leader 坐下来思考技术选型的时候,很容易发现,其实除了 Electron,没得选了。
  • Daily.dev: 自从把它作为 New Tab 的启动页以后,工作效率直线下降,太吸引人了,「7 Killer JavaScript One-Liners that you must know」你能不点进去看吗?我愿称其为码农抖音。
Did you enjoy this issue?
Hwang
By Hwang

恣意生长是一份自我观察的 Newsletter。这份 Newsletter 会为读者提供个人的关于视角/产品/设计/编程 四个方向内容的思考和感悟,他们会是杂糅而又恣意的。

In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
Powered by Revue