作者归档:白宦成

关于白宦成

独立开发者, 自由职业者, 写作者

手机丢了以后,都可以做什么来挽救?

手机丢了以后,都可以做什么来挽救?

这个周末,我来南京游玩,在即将登机的时候,我发现我的手机遗失了。以下是我做的事情的记录,希望给你后续一些帮助。

在深圳机场做的

1. 沿路寻找

我大致记得最后使用手机的位置,便沿着路重新回头去寻找我的手机。

2. 联系机场的失物招领处

因为我还怀着一丝希望有人可能捡到手机送到失物招领处。所以我马上跑到失物招领处去登记我的手机遗失信息。

3. 借手机给我自己的手机打电话

借用别人的手机给自己的手机打电话,可惜当时就无法接通。只得作罢。

在南京做的

因为即将登机,所以我来不及做太多的事情,只能先前往南京,到南京再做安排。

为什么会是这样?
我是这样想的:我可以不登机,然后在机场找手机,有一定的概率找到手机,但损失了南京的行程;
我也可以登机,然后等待机场后续联系我;
由于我已经在沿路找过了,所以不太可能依赖自己的能力找到,只能通过其他人来找。
所以我留下的意义并不大。

1. 打电话给 10086 进行停机

落地南京后,我就赶紧借电话,拨打 10086 转人工服务办理停机业务。

需要注意的是:停机业务需要联系手机号归属地的 10086 ,你可以拨打区号 + 10086 来找到你的归属地 10086;

办理停机业务需要提供以下信息:

  1. 服务密码:服务密码即可办理停机业务。
  2. 如果你忘记了服务密码,则需要提供三个通话记录,需要分别满足,上个月、这个月、这周,且每次通话时长需要超过 3 分钟。

很显然,服务密码更简单,通话记录的提供比较困难,提醒大家一定要记好服务密码。

停机是为了确保你的手机卡不会被别人用来接受短信验证码,并 hack 你的账号。

除了停机,如果你的手机设定了 PIN 码,也可以不用担心这个问题。但考虑到你的手机可能无法找回,也可以直接办理停机。

2. 打电话给所在地 10086 ,咨询哪些营业厅可以办理异地补卡

异地补卡并不是每一个营业厅都可以办理的,因此,你最好打电话给 10086 ,请求他们帮你找到距离你最近的营业厅,进行补卡业务。

得到回复后,你就可以前往对应的营业厅进行补卡手续。补卡一般会需要 10 ~ 20 元不等的制卡费。

3. 使用 Apple 的 Find My 查找功能定位手机

这个我其实当时没想起来,如果想起来或许就可以更快的解决问题。

Apple 提供了一个 Find My 的功能,可以找到你的手机的位置,并让你的手机响铃等。

谈独立开发者

谈独立开发者

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

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

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

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

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

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

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

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

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

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

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

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

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

在产品触达用户之时,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

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

为 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',
        },
    ],
    // 你的其他配置
};
  1. 移除项目中标记为 Scss 的语言

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

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

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

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

npm uninstall @wxa/compiler-sass
// 或者
yarn remove @wxa/compiler-sass

总结

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

wxa.js 引入 tailwindcss

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

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

@tailwind base;
@tailwind components;
@tailwind utilities;

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

npx tailwindcss-cli@latest build ./src/tailwind.css -o ./src/tailwind.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

可以看到,去除 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: {},
    }
}

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

移除后的效果

4. 在 wxa.js 中引入

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

npx tailwindcss-cli@latest build --no-autoprefixer  -o ./src/tailwind.wxss

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

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

@import "./tailwind.wxss" 

优化

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

「作假」的模范人物?

「作假」的模范人物?

今天回老房子,拍了张照片,是当地针对全国道德模范的一段 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 人来说,是一个非常正常的数字。

总结

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

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

参考文献

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

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

豆瓣链接

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

收看渠道

Netflix

观影感受

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

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

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

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

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

豆瓣页面

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

观看渠道

Netflix

观影感受

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

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

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

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

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

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

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

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

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

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

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

做事要认真

做事要认真

做事认真与否,其实是非常明确的。对于业内人士来说,你这做的事情的工作量有多少,一目了然。即使在技术细节上不懂,但你所花费的时间、对于细节的打磨,是很轻松的可以看出来的。

而细节,会让读者、 听众、观众对你满意。可能你技不如人, 很难获得别人的认可,但你所付出的时间和精力,也值得他人的赞许。

有没有花费了精力也做不好的呢?有的,但其实很少的。