Freelancer

谈独立开发者

今天可能有些同学因为「独立开发者」这个标签关注我的推特,不过这个号可能你们看不到太多关于独立开发者的「技术」分享,因为「技术」不是独立开发者的关键,对于独立开发者来说,技术够用就行。反而是产品、市场、商业、运营的能力对独立开发者来说会更有帮助。我并不推荐经验不足的同学做独立开发者。

因为对于独立开发者来说,能够独立打造一个产品,是基本功。你需要能够 Cover 掉整个项目的几乎所有流程,然后才有资格成为独立开发者。如果你的技术不全面,那你就必须想办法解决这个问题。可以是借助云服务、可以是借助 No Code 工具。不要让技术把你卡住了。

当产品研发不会成为你的阻碍以后,你就踏上了独立的路线。成为独立开发者的路径是漫长且枯燥的,但同时也是开心的。因为你可以做你喜欢的事情、做你想做的产品、服务你想服务的人,并从中获得支付,养活自己。

相比之下,我认为有商科、金融等背景的人会更容易成为独立开发者,原因是更具备理解商业逻辑的能力。如果你不是,或者你不能理解,那就找一些书,看看商业世界是如何运转的,你又如何从中提供价值,赚取收益。当你开始思考商业的问题时,你就真正的走上了独立开发者的道路。

在前期,你可能做了大量的事情,都是在尝试,在锻炼,但不要害怕,开发产品本来就是一个困难且复杂的事情。失败也是大概率的事情。但你可以从自己的每一次开发过程中吸取教训,让自己的下一次产品比这一次更加成功。

作为独立开发者,我不太建议你采用广告的方式来获得收益。广告的方式本质上是流量生意,你的收入和你的用户的增长并不是线性的。而且流量生意对于资本、渠道等关系的要求很高,对于绝大多数开发者来说,并不适合。关注一个小众领域,服务一小撮人,是一个比较简单且实用的路径。

你从每一位用户(客户)身上收取费用,你的用户增长和收入是呈线性关系。相比于「可能是指数型增长的广告业务」个人觉得会更适合刚刚开始的同学。当然,如果你确实有明确的流量入口,把控了流量,那做广告型的业务也未尝不可。

我常说,「和别人做一样的事情,就不要预期和别人有不同的结果」,做独立开发者就是一个试图做和别人不一样的事情,在这个过程中,你是孤单的,但也是快乐的。作为开发者,我们能够选择「做自己喜欢且可以赚钱的事情」,是非常幸运的,别浪费了这种快乐。

在我看来,独立开发者和作家、播客主播一样,都是创作者。这部分就像 @zhufengme 说过的「创作者不能缺钱」。如果缺钱,就不太好搞创作了,那么穷困潦倒,要么不得不放弃一部分原则,以养活自己。处在一个比较舒适的状态下,认真去做自己喜欢的事情,反而可能更容易走出自己的路。

为什么太缺钱的人或者太关注钱的人可能反而不容易成功?原因是,如果你太过于关注钱,你就变得和商业公司一样了,追求的是利润。但,从追求利润的角度来看,商业公司一定会在这个事情上拥有比你更加强大的能力和实力。所以我不太喜欢做有强资本属性的事情,因为你很难在这个维度和大企业竞争并取得成功

独立开发者不要追求效率,而是要想办法追求美好的体验,就如 @RioJot 和黄海在疯投圈「51.从泡泡玛特谈起:物质消费中的情感体验」中提到的,我们有太多的企业去追求且擅长追求效率,而情感体验,是作为个人能够做的更加极致的部分。效率从各个角度来看,你都不如大企业能够做的更好

但你可以在情感体验和观点(opinion)中获得价值,@plidezus 的 Flomo 就是一个很典型的拥有自己的 Opinion 的产品。而研发同学们特别熟悉的 Rails 的母公司 Basecamp ,也是一个非常典型的 Opinion 导向的公司。他们通过构建一种 Opinion ,找到和自己同频的人,然后向他们售卖针对这个Opinion的产品

在产品触达用户之时,DevRel 团队都要做什么

经尾尾邀请,在“聊聊 DevRel && 技术运营”群做了一次关于 DevRel (开发者关系)的分享,以下是分享内容,希望对你有帮助。

Slides 地址:https://docs.google.com/presentation/d/1n6XBLfmpSCDg3196LIn_8FGKIqkCIp-qN9sMQ-uxzVk/edit?usp=sharing

《布道之道》链接:https://www.ituring.com.cn/book/736

直播回放:https://bytedance.feishu.cn/minutes/obcnxp28x2898p51qk37zrzy

text

为 wxa.js 构建的小程序移除 scss 依赖

wxa.js 默认使用的样式语言是 scss,所以其默认创建的项目就会要求安装 node-sass,但由于 node-sass 依赖了 binding.node 等包,导致常常会出现 node-sass 安装失败的问题。

如果你并没有在项目中使用 scss ,则可以考虑将你项目种的 node-sass 移除,从而缩小项目的依赖体积,提升项目安装成功的概率。

思路

由于 wxa 默认使用了 scss,因此,我们需要移除项目中针对 scss 的配置,并移除代码中的 scss ,这样才能保证后续在编译的过程中,不会调用 node-sass 的依赖。

步骤

  1. 移除 wxa.config.js 中关于 scss 的配置

在 wxa 的默认配置中,配置了 sass/scss 的依赖,我们如果不移除这个依赖,就会导致后续在构建的时候,自动安装相关依赖。

因此,我们需要在 wxa.config.js 中添加 use 相关配置,且仅保留 babel 作为依赖,具体修改如下:

module.exports = {
    plugins: [
        new ReplacePlugin({
            list: envlist,
        }),
    ],
    // 你的其他配置
    use: [
        {
            test: /\.js$/,
            name: 'babel',
        },
    ],
    // 你的其他配置
};
Code language: JavaScript (javascript)
  1. 移除项目中标记为 Scss 的语言

在移除了 wxa.js 的构建依赖后,接下来需要移除代码中关于 scss 的标示,从而使我们的代码可以被正确的渲染工具所渲染。具体修改如下所示,右侧为修改后的结果

  1. 移除 package.json 中的 相关依赖。

当我们完成了上述的操作之后,就可以放心的移除系统中关于 sass 的依赖了,从而减少整个项目的体积和对 node-sass 的依赖。

你只需要执行如下的命令,就可以移除项目中关于 sass 的依赖了。

npm uninstall @wxa/compiler-sass
// 或者
yarn remove @wxa/compiler-sass
Code language: JavaScript (javascript)

总结

scss是一个好的语言,但 node-sass 却不是一个好的工具,如果你不使用它,不妨将其移除,提升你的项目构建速度。

text

wxa.js 引入 tailwindcss

TailwindCSS 是我最近一段时间使用比较多的 CSS 框架,相比于传统我们习惯的前端框架,它的限制更少,你可以根据自己的需要来编写样式。如果你配置了清除没用到的 CSS,TailwindCSS 的体积甚至可以远小于其他框架。

也因为上面的这些因素,我也自然而然的会选择将其放在小程序中来使用。而由于我使用的是 wxa.js ,所以这里也是一个对应的 wxa.js 的教程。

安装

1. 安装 TailiwndCSS 到你的项目中

由于 Taildwind 默认推荐使用的是 PostCSS,但其需要的是 PostCSS 7 或者 8 ,但 WXA.js 提供的 PostCSS 插件使用的是 6 ,所以这里我就选择不将其作为 PostCSS 插件来安装。

在 WXA 项目根目录中执行如下命令,会在你的项目根目录中生成一个 tailwindcss.config.js,它会作为后续你的项目配置的配置文件。

npx tailwindcss-cli@latest init
Code language: CSS (css)

随后,在你的项目根目录创建一个 tailwind.css 文件,并在其中加入如下代码,这个文件作为你后续样式基础文件。

@tailwind base;
@tailwind components;
@tailwind utilities;
Code language: CSS (css)

添加完成后,你就可以执行如下命令,来生成一个默认的 tailwindcss 样式文件。

npx tailwindcss-cli@latest build ./src/tailwind.css -o ./src/tailwind.css
Code language: CSS (css)

生成的效果如下,可以看到,未任何处理的情况下,整个 CSS 文件足足有 3.81 MB,不过不用担心,我们可以清除其中的样式。

未做清理

如果你希望后续不输入这个命令,可以将其添加到你的项目的 package.json 中。

2. 移除默认的浏览器自动添加的 prefix

由于不同浏览器在不同的样式上可能有所不同,tailwindcss 会在生成的时候帮助我们生成一些特定的前缀。但小程序不涉及到浏览器的兼容性问题,所以我们可以关闭 taildwindcss 的 autoprefixer。

将刚刚的生成命令中加入 --no-autoprefixer 的参数,就可以生成不含 prefix 的 CSS 文件

npx tailwindcss-cli@latest build  --no-autoprefixer  ./src/tailwind.css -o ./src/tailwind.css
Code language: CSS (css)

可以看到,去除 prefix 后,我们的文件缩小至 3.46MB。

去除 prefix

3. 移除不用的样式

tailwindcss 提供了根据页面结构分析使用样式的功能,从而可以实现在构建生产版本之时,移除没有使用的样式,从而可以达到缩小样式的目的。

在项目中的配置 purge 属性,就可以实现 tailwindcss 自动分析 wxa 文件,从而移除没有用到的样式。

module.exports = {
    purge: ['./src/**/*.wxa'],
    darkMode: false, // or 'media' or 'class'
    theme: {
        extend: {},
        screens: [],
    },
    variants: {
        extend: {},
    }
}
Code language: JavaScript (javascript)

配置了 purge 属性后,可以看到,样式文件锐减到 9.93KB (因为我使用的样式很少)

移除后的效果

4. 在 wxa.js 中引入

修改生成文件的命令,使生成的文件的后缀为 wxsss,从而可以继续使用微信小程序的 @import 语法。

npx tailwindcss-cli@latest build --no-autoprefixer  -o ./src/tailwind.wxss
Code language: CSS (css)

重新生成样式文件后,只需要在 app.wxa 文件中的 style 块中加入如下引入代码,在项目中引入 tailwindcss。

因为 tailwindcss 只生成一个样式文件,因此,只需要在 app.wxa 中引入,即可确保所有页面都可以正常使用 tailwindcss

@import "./tailwind.wxss" 
Code language: JavaScript (javascript)

优化

实际上,taildwindcss 的体积还可以进一步优化,你可以完全移除掉那些你没有用到的属性,从而让你的 css 文件特别小,从而控制小程序样式的大小。

black flat screen tv turned on displaying yellow emoji

「作假」的模范人物?

今天回老房子,拍了张照片,是当地针对全国道德模范的一段 PR 话术,我觉得其中的数字很有意思,便拿出来聊一聊。

奇妙的数字

首先,要说明的是,这里面我认为有问题的数字是「观众高达上亿人次」,这个描述在人民网的介绍中并不存在,所以我认为是下面的宣传人士为了夸大宣传效果而估出来的数字。

在短短的一段话中,涉及到了几个数字,我们可以通过简单的算术来验证真伪。

19 年放映 13000 场电影:这个数字我认为是相对比较可信的。原因是,19年共计 6935 天(不含闰年),考虑到闰年,按 6939 天计算;假设一天放两场,就已经达到了 13878 场,这个数字总的来说,可以接受。毕竟全年无休,在很多岗位上都是这样的。

24 年放映 14万多场次:这个数字我认为也是比较可信的,24 年共计 8760 天(不含闰年),考虑到闰年,共计 8766 天。14 万 / 8766 天,平均下来每天 15 场,按照一组人能放两场(按照上面一组数据的推送得出)。其实他的团队也就 7 组人,是一个比较正常的数字。

14万场覆盖 1 亿人次:这个数据我认为不可信,我们按照保守的 1 亿人次,14万场提升到 15 场,平均下来每场 666 人。而中国目前最大的电影院放映厅为「中国科技馆新馆影院IMAX影厅」,共计 632 个座位(信息来源:百度百科),不可能每一场都将人带到中国科技馆新馆影院 IMAX 影厅。可能有人会说,那农村就不能大家都来看么?当然可以,但这个数据是 平均下来每场 666 ,意味着有的场次可能远超 666 ,有的场次不如 666 人。这在当前的情况下,根本不足以实现。

此外,关于这个一亿人次,还有一些辅助信息,2013 年,郭年华女士所在的祥符区人口为 76 万人,假设该团队每年为该区内每个人播放一次电影,24 年共计覆盖 1824 万人次;这76万人每年都要看 6 部电影,才能填的上 1 亿人次的坑。而实际上,我们还需要扣除这 76 万人当中不适合看电影的,比如生病卧床的、年纪大的、年纪太小的、要上夜班的,这个数字远不止于此。

实际上,在我看来,14万场覆盖一千万人次或者两千万人次,我觉得都是相对比较靠谱的,因为这样你的场均就是 66 人或 100 人。66 人和 100 人的数字相对于现实场景的 50 ~ 80 人来说,是一个非常正常的数字。

总结

从宣传的角度来看,数字更大可以获得更多的信服度,为这些模范树立他人所不能为的事情的印象。不是一件坏事,但,数字再大,也需要遵循客观规律,不然,对于模范的公信力,反而是一种伤害。

试问,你会相信一个作假的模范么?

参考文献

black and white typewriter on white table

《无论如何我爱你 If Anything Happens I Love You》观后感

豆瓣链接

https://movie.douban.com/subject/35225555/

收看渠道

Netflix

观影感受

这是一个小短篇,不长,故事也很简单,讲述了一对父母从痛苦到解脱的故事。

因为美国校园枪击案,一个小女孩因此而去世,他的父母因此消沉,整日无言以对。母亲在洗衣服时,意外发现了女儿的衣服又被洗,痛苦之下,意外碰到了足球,致使女儿的留声机再次想起,使得父母二人重聚,共同回忆。

回忆中,女儿的影子让父母的影子重新回到了一起,重回当初的温馨,而这背后,也映射了当初出事之时,女儿给父母发的信息 —— 「If Anything Happens I Love You」,无论如何,我爱你。

flat screen television displaying Netflix logo

《监视资本主义:智能陷阱 The Social Dilemma》观后感

豆瓣页面

https://movie.douban.com/subject/34960008/

观看渠道

Netflix

观影感受

作为一个互联网从业者,其实智能推荐算法在我看来,特别的常见。但说句实话,我自己其实对智能推荐算法不甚了解。更是不熟悉他背后的机制。倒是我们常说的「信息茧房」这些,都有所耳闻。而这部影片中,就在介绍这个内容。

这部影片我想看了很久,但一直断断续续,刚刚才看完。

这个影片先用一个故事 「Ben」的生活,来介绍了推送、提醒这些功能的用途,也让我深刻的感受到,这些东西对于我们生活的影响。

另一方面,用 Ben 的生活,和他误入极端组织集会的场景,展示了社交媒体对于人们观点的影响,颇为恐怖。

我们需要学会梳理自己的信息源,让自己可以更好的理解这个世界。

推荐每个人去看这部影片。

black flat screen tv turned on displaying yellow emoji

onCall 别说「报错消息很明确了」

今晚在写飞书 Bot ,遇到了一个无法解决的问题的时候,不得已,找到了飞书的 OnCall。但在聊天的一开始,OnCall 的同学便回复了「报错消息很明确了」的回复。 让我开始有点生气。 生气的点在于,作为一个专业的开发者,onCall 之前查文档我还是心里有数的,如果问题可以被解决,我就不会选择进入 onCall 的流程。这样的回复有点质疑我的专业的感觉。 但是,换个角度来思考,onCall 同学可能确实是在忙,有点不爽。可以理解。 那有没有一个更好的办法来规避这个问题?

  1. 回复:「你好,这个报错文档中有对应提醒,是否已经按照文档描述调试过了?」这样的回复虽然含义差距不大,但缺少了「质疑」的感觉。
  2. 直接回复错误码对应的问题(但这部分其实是需要工具支持的,比如帮助 onCall 同学提供一个快速回复的工具,降低成本)

希望各位 onCall 同学都可以规避这个问题,不要陷入 onCall 导致脾气暴躁的环节。