主页

记录小宝的成长经历|大事记

这是一款为了记录小宝成长经历的小工具。

时间过得很快,一眨眼,小宝已经 9 个多月了,现在让我回想,她什么时候第一次翻身,什么时候第一次坐起来,什么时候第一次发出「爸爸妈妈」的声音,我已经记不太清楚了。

这些都是小宝成长过程中,有意义的一些时间节点,我想要记录下来,于是,就有了「大事记」这个小工具。

本质上来讲,这又是一个备忘录类工具,截止目前为止,我已经做了好几个备忘录类的工具了。

  • 收藏地址是为了记录地址信息
  • 计算日子是为了记录日期信息
  • 账号箱是为了记录键值对信息
  • 写给未来的信是为了记录大文本信息

大事记是为了记录有序列表信息,按照日期顺序显示事件。一条一条翻看下来,还是非常有意义的。

页面几乎是现成的,并没有做细节上的优化,看起来还凑合,整体的框架就是两个 List,一个用来保存事件列表,一个用来保存时间节点列表。

大概的样子如下图所示:

后面可能会有一些页面样式上的调整,这个版本就先这样了。

完。

阅读更多

第一次回武汉|写给宝宝的第三封信

这次十一假期,小宝第一次回老家武汉,经过七八月份的几次短途旅行,使得这次的旅途,显得没那么困难,同样让小宝经历了,人生很多的第一次。但是,生活总是没有一帆风顺的,有欢乐,也会有悲伤。

还是希望以信件的方式,来记录这个经历,以我对小宝的角度去叙述。

准备阶段

第一次坐飞机那天,你刚刚 9 个月零 2 天。

对于这次回家的旅途,你妈唯一担心的因素就是距离太远,旅途中的时间太长,怕你受不了。

所以,衡量再三,最后还是选择了飞机出行,这应该是最快的出行方式了。

由于你是第一次坐飞机,你爸妈坐飞机的次数也不多,为此,从来不准备出行计划的我,居然写了一大篇,就是为了尽量减少路途中的不确定性因素,让你少一些折腾。

这是我写的出行计划,写的过程中,就把那天出行的大致过程走了好几遍,需要提前准备的,都已经准备妥当,例如:办理停车服务,最近的入口,值机柜台等等。

从实际出行情况来看,这个计划中的时间节点把握得还是非常准确的,没有太大的出入,时间都在可控范围内。

去机场

出发那天,早上 7 点准时从家里出发,驱车前往机场附近预定的停车场,对于坐车,你一点都不陌生,1 个多小时的路程,你都能睡上将近半个小时。

到达停车场后,有专门的摆渡车带我们去机场,到达机场办理值机托运,整个过程都很顺利。

唯一意料之外的是,进机场的时候,你又睡着了。幸好提前准备了可上飞机的婴儿车。

带你出行,婴儿车绝对是必备,暑假去你姥姥家,没有给你带上,你爸妈现在想想都腰疼。**

安检的时候,必须要把你抱起来拍个照,这下就把你弄醒了,你就这样迷迷糊糊的进入了候机厅。

我们几乎是提前了 1 个半小时,就已经到登机口等待了。

这个时间足够让你吃喝玩乐耍上一阵子了,刚刚睡过一觉,这时你的状态还是不错的。

上飞机

你这就样子,光着脚丫子,被推上了飞机。在走廊的过程中,你一脸的疑惑和好奇,那样子还是挺有趣的。

婴儿坐飞机,有一点需要注意:不要让宝宝在起飞和降落的时候睡觉。

由于气压变化的原因,睡觉的时候,容易造成耳膜损伤,这个时候最好让宝宝做吞咽动作,或是哭闹。

中午一直没有睡觉,飞机降落的时候,你正好困到极点了,怎么弄都醒不来,抱起来抱着睡,把你举起来,你就立着睡。

最后没办法了,只能掐小脚板了,那半个小时,我相信,你的内心是崩溃的,肯定心想「哪有这样的爹妈」,一睡着就给掐醒了,然后眼都没睁开,烦躁的叫上几声,就又睡着了,接着再被掐醒,就这样重复了 N 回。

换做是大人,我想早该怒了。看到你难受的样子,我跟你妈也于心不忍,不过没办法,也是担心你会受到一丁点的伤害。

下了飞机,爷爷奶奶过来接的你,你很不给爷爷面子,一见面就哭。不过在车上,跟你奶奶倒是玩得很开心。

路上终归还是扛不住了,在妈妈的怀抱里睡上了一觉,我们到家的时候,已经是下午 16 点了,从早上 7 点出发算起,我们在路途中待了 9 个小时。

这可能是你在路上,时间和距离最长的一次旅途了,这次旅途,我们一起走过了将近 1400 公里。

众星捧月

来到一个陌生的环境,周围一堆陌生的人,最关键的是,这一堆人似乎都在关注着你。这众星捧月般的招待,一下子就让你哭闹不止,久久不能平息。

这就是刚刚下车时的情形,老家小镇就是这样,遇到一点新鲜事物,都希望能够凑近看上一看,发生了什么事情,而你,对于他们来说,再新鲜不过了。

在鲜有人情来往的公寓型高楼中久住的你,哪能接受得了这般的待遇,不安的哭闹也是意料之中的事情了,不过,这也是你的一种经历。人总要去接触让自己不安的事物,克服了,也就成长了。

进屋后,没有了陌生的面孔,你的心情稍微平复了,给你一些没见过的东西,你总能抱着它啃上一阵子,好哄是你的一大优点。

然而,这才仅仅是开始,接下来几天都会有亲戚前来「拜访」,毕竟老家的亲戚都还没有见过你。

原本我最担心的是办酒席那天,老家有个习俗,孩子出生及 1 岁的时候,都是要摆酒席的。出生至今,一直没有回去,这次难得回来,你爷爷奶奶就张罗着,赶紧把你 1 岁的庆生提前给办了。

办酒席那天,将会来更多的亲戚,对于你来说,将是更大的挑战。

从小你就比较胆小,认生得厉害,不过,适应能力却是相当强的,这一点我深感荣幸。

短短的两天,你几乎不怎么哭了,办酒席的那天,把你抱着来回窜桌的时候,你竟然一下都没有哭,抱着一个一次性塑料杯,啃的饶有兴致,可爱至极。把我们惊喜坏了,特别是你爷爷。

四代同堂:老太,姑奶奶,妈妈,还有你。

我竟然哭了

看着你前几天兴致高昂的玩耍,本以为所谓的「水土不服」在你这里根本不存在,然而不幸的是,还是让你中招了。

也许是南方的冷热跟北方的就是不一样,单纯看温度表上的气温,并不能采用跟北方一样的穿衣方案。

相对而言,十月份的武汉已然比较「温和」了,但还是大意了。

另外,在小镇上,「乡土气息」总是那么浓烈,这些都是你很少经历的。空气中总是弥漫着,烧柴火的烟雾味,连晚上都不例外,这在城市里定然是不存在的。

有两天的晚上,我都被烟味给熏醒了,搞得那几天,我的嗓子一直是疼的。从小我就对烟味特别敏感,而你就睡在我的旁边,我很担心是否会对你造成影响。

果不其然,回去第 3 天就发现你睡觉的时候,呼吸有杂音,并伴随着咳嗽,早起给你测量体温,37.5,有一点发热,猜测定是嗓子有炎症了。

于是,就带着你去县里妇幼保健院,离家里 1 个多小时车程。到了妇幼保健院,医生检查果然是嗓子发炎了,需要抽血化验确诊,确诊结果「细菌感染支气管炎」,需要先做皮试,然后打吊瓶。

自打你出生,除了打育苗的时候扎过针,一颗药都没有吃过。仅仅是今天一天,你就被扎了 3 针,手指一针抽血,手腕一针皮试,脑门一针吊瓶。

在医院里,从来都是紧张凝重的心情,况且带着生病的你,我跟你妈还有奶奶,也只能被人支唤着跑来跑去,排队缴费、排队抽血、排队看单,一家人的内心都是紧绷着,谁也不说话,都是第一次经历这种事情,情绪比较复杂,安静得可怕。

唯独伴随着的是你的哭声,从没见你哭得如此伤心,抽血的时候,已经让你哭得撕心裂肺了,好不容易让你吃点奶,平静了下来,却被告知要打吊瓶,在做皮试的时候,我就看到你妈眼睛已经红了。

对于医院的护士来说,给你打吊瓶,也许是再正常不过的流程了。然而,对于我们来说,却是战战兢兢。

护士担心你妈妈按不住,就让我压住你的胳膊,扶着你的脑袋,你奶奶按住你的双腿膝盖。你就这样像粽子一样,被固定在了打针台上。

这种架势,还没有开始扎针呢,你就开始哭了,一定是害怕极了,扎针的时候,哭闹得更加厉害,盯着我的眼神,像极了是在求救,看得我鼻子酸酸的,看我不管用后,又斜眼看向站在旁边的妈妈。

打完针之后,我紧紧的抱住你,不让你挣扎,看着你哭得伤心的面孔,我再也控制不住自己了,强忍着眼泪,哭了。

我从来没有想过,面对你的一次打针,我竟然哭了。天天陪着你玩耍,每天看着你的成长,在我心中,你无形中就成为了那个我最关心的人。而当看到你伤心欲绝的样子,我又无能为力的时候,理性已经无法控制我自己了,于是便在大庭广众之下,哭了。

生病这两天,我跟你妈几乎就没有怎么睡好过觉,去医院头一天晚上,我就睡了 2 个多小时,第二天又在医院奔波了大半天。

你妈妈在回京那天也病倒了,我都不知道是什么支撑着我,也许是责任吧。

看着你能够安静的入睡,我就倍感欣慰,这次的经历让我感受到了作为一个父亲的责任与义务。

回京

凡事经历过一次,第二次总是会显得从容得多,回来的时候,依旧是飞机,时间估算得更加精准了,不慌不忙,最后一个上飞机,最后一个下飞机,在飞机上,你几乎是睡了一路,完美避开了起飞降落。

下午两点的飞机,到家也差不多七点了,回来又继续吃了两天药,喂药喝水也是个斗智斗勇的活。

这两天渐渐的好了,看着你坐在地垫上,玩得正认真,我叫你一声「小宝」,你抬头向我眯眯笑,那一刻,心里暖暖的。

完。

阅读更多

发布一个课程《微信小程序开发实战》

根据自己从零开始做「字节加工厂」这个小程序的经验,我计划写一个《微信小程序开发实战》的课程,当前已经完成了「入门篇」,介绍微信小程序开发,从 0 到 1 这个过程。

虽然说是入门篇,但是涉及的内容还是挺多的,也并不基础。有些内容涉及到 Web 前端的知识点,还有些内容涉及到 Node 知识点,例如「使用云函数开发」这篇,示例代码中还涉及到了 Node 中 https API 的使用。

技术相关的内容,基础大抵都是类似的。看似形形色色的不同形态,不同语言,不同架构,其实只是应用层面的使用方法不同而已。

最重要的还是基本功,越是基础的东西,越难习得,当然它的价值也最高。

这仅仅指的是技术层面,技术层面虽然很难,但还不是最难的,最难的是思路,也就是「产品能力」。

很多时候,我们学会了很多技术,却不知道用来做什么。

这个课程,我也没有办法去解决这个问题。

能够解决的是,帮助你将官方文档窜起来,从实际问题出发,去解决问题。文档终归是文档,它只是罗列出使用说明,我希望通过这个课程,带你学会实际解决问题的能力。

按照我的学习路径,《入门篇》我总结了 12 篇文章,如下目录:

  1. 了解小程序的页面逻辑
  2. 从写一个完整的页面开始
  3. 使用 Map API,完成一个页面交互
  4. 使用 Storage API,实现数据持久化保存
  5. 使用 Canvas API,做一个分享卡片
  6. 页面传参的几种方式
  7. 学会使用第三方 NPM 扩展包
  8. 使用 request API,调用第三方接口数据
  9. 使用云函数开发,绕过设置合法域名信息
  10. 学会云函数的本地测试以及云端测试
  11. 聊一聊小程序的服务端开发
  12. 学会使用云开发数据库能力

根据我的经验,假如你真的学会了上述文章中提到的知识点,微信小程序开发肯定是入门了,如果再深入一点,可能往「全栈开发」也踏入了半只脚。

当然,这个入门篇并非适合所有「新人」,它是根据我的学习路径而成,我本身是具备 Web 前端 以及 Node 开发经验的。

所以,如果你正好也有类似的开发经验,那么,这个入门篇的内容,对于你而言,可能要容易得多了,至少也能帮你节省一些时间,少走一些弯路。

写完《入门篇》之后,又花了点时间,整理成了 PDF 电子书,欢迎加入我的免费知识星球「字节加工厂」,获取电子书。

写完「入门篇」,后面计划开始整理「效率篇」,文章将会同步在更新在 GitHub 上,仓库地址:https://github.com/pengloo53/miniprogram-articles

完。

阅读更多

很多时候,技术能力并没有那么必要

无意中发现一个好玩的站点,HTTP Cats,使用喵星人的照片来描述 HTTP 状态码。例如,最常见的 404 Not Found 的照片如下:

觉得挺有意思的,于是,就想到要移植到小程序「字节加工厂」中,网站首页应该是个静态页面,但是开发者提供了简单的 API,可以方便获取某个状态码对应的图片。如下:

https://http.cat/[status_code]

所以,移植工作就容易得多了,直接将图片 src 指向 http.cat 就可以。

但是,这样会有一个问题,假如 http.cat 的图片服务器 down 了,小程序里的照片就全部无法访问了,最保险的办法还是将图片全部保存下来。

下载图片最直接的办法就是打开图片 URL,然后 Ctrl + S 一张一张的保存即可,50 多张照片,怎么着也得 20 多分钟吧。

可是这样并不符合我的定位呀,做着提高效率的小程序,然而自己却干着这么低效的事。

于是,花了几分钟熟悉了一下 HTTPS 模块的使用,又花了几分钟写了下面十来行代码。

又花了几分钟,简单测试了下,然后运行程序,一下就 down 下了所有照片,最后删掉一些干扰数据,就搞定了。

总的来说,似乎花的时间差不多,但是,这种方式才符合身份嘛。

另外,如果再遇到类似的站点,下载图片的效率就更高了,几乎不需要花时间,改下 URL 就行了。

别说,还真有一个用「狗狗」图片来描述 HTTP 状态码的类似网站: https://httpstatusdogs.com

图片全部准备就绪,小程序代码很快就搞定了。

接下来就是要与作者取得联系,用人家的图片资源,需要人家的授权,这是最基本的互联网规矩与礼貌。

于是,在网站的最底部,找到了作者的 Twitter 以及该站点的开源仓库。

翻看了一下作者的 Twitter,然后发了条信息,请求授权。

最后,看了下 GitHub 仓库,赫然发现,所有的图片都直接放在了仓库中,直接打包下载就可以了。

上面折腾半天,又白忙活了。

题外话

懂一点技术很重要,但是,技术能力,在很多时候,并没有那么必要。

在这个极度细分市场的大环境下,很多事情的成功,并不需要你必须具备技术能力,而更多的是需要商业能力,产品能力等等。

完。

阅读更多

BMI 计算器

这绝对是个为了凑数的小工具,几乎都算不上是什么需求,完全是为了换个脑子,顺手就完成了。

BMI

BMI(Body Mass Index) 叫做身体质量指数,主要用于统计,是目前国际上常用的衡量人体胖瘦程度以及是否健康的一个标准。

它有多个标准,因为每个地域的标准身材还是有一些差异的。中国有单独的一个标准,另外还有国际标准,欧洲标准等等。

BMI 的计算公式都是一样的(体重除身高的平方),只是结果的标准不一样。例如中国标准里,18.5 ~ 23.9 属于正常身材;而国际标准里,18.5 ~ 24.9 属于正常身材。

另外,它的结果也没有多大的实际意义。假如两个人身高体重都一样,但一个人浑身都是肌肉,而另一个人都是脂肪。BMI 的值是一样的,但由于身体组织的比例不一样,身材可能就差远了。

所以,BMI 只是一个参考值而已,毕竟仅仅通过「身高」和「体重」两个指标,并不能说明一个人的身体素质怎么样。

产品

它的功能也相当的简单,一个表单页,一个结果页,就搞定了,剩下的就是页面的交互了。

不想要太复杂,也不想过于简陋。单纯显示结果数值的话,未免太简陋了。于是,我就找了几个插图,配上一段调侃文字,简单做个排版,就这样了。设计样式如下:

看起来似乎还凑合,后面又加了个历史记录保存的功能,这样,这个工具也算是完整了。

原本就是一个很简陋的小工具,再怎么伪装也就那样了。下图就是整体的样子,偶尔记录测算一下,还是有一丁点的价值的。

阅读更多

记一次拔牙经历

距离上一次看牙已经是 3 年前了,也就是说,这颗坏牙已经存在至少 3 年以上了。

中间这么长时间都没有去看,并不是它一直没有发作,只是因为我懒,又不是啥病,对吧。

牙疼不是病,疼起来要命。

1.

除了「懒」这个原因外,还有一个原因,那就是在北京看个病实在太费事了。犹记得,3 年前那次,我只是去洗个牙,就去了 3 回。

第一回,去医院排了半天队,啥也没干,领了两个单子,一个拍片,一个是血验单。对,你没看错,洗牙要验血,交了钱,验了血,结果 3 天后拿。

第二回,拿了结果,告知当天不受理洗牙,然后就预约了个受理的时间。

第三回,排了 2 个小时的队,洗了大概二十来分钟,开了一些药和漱口水,也花了一上午时间。

验血+拍片+洗牙,共花了将近 1000 块,费用就不多说了,就这效率就让人很心寒。

这是一家二甲医院,还好离家近,少了路途的折腾。

2.

有了这次经历,不到不得已的情况下,能坚持就坚持,绝不轻易去医院,于是一晃眼 3 年过去了。

这一次也只是正常发作而已,应该是前两天吃「老干妈」惹的祸,本来就有炎症,刺激一下,就发作了。

要是我自己,闷声疼两天,也就过去了,可是疼的时候,被媳妇发现了,于是她那过不去了,又是给我查医院,又是给我挂号的,我要是再推脱不去,怕是说不过去了。

于是就下定决心,索性去拔了吧,拔不拔牙都是次要的,咱也不能辜负媳妇的用心不是。(论媳妇的重要性)

3.

起了个大早(比娃儿醒的还早),因为 8 点之前,我得取号,这次去的是「北京口腔医院」,距离我家里,也得 1 个半小时呢,我可不想再去上次那医院了。

不到 8 点我就到了,8 点准时叫号,不是一个一个进,而是 5 个一起进,好像一共 4 个诊室(我所在的这个科室)。

也就是说,一下子能同时看 20 个号,我是第 17 号,原本以为怎么着也得等 1 个小时吧,谁知道第 1 个就上了。(暗自佩服这效率)

这应该是牙科的特殊性,因为每个诊室里都能放 5 个操作台,每个操作台相对独立,配有两名医生(也可能是护士)。

进来之后,直接询问诉求,我的诉求就是拔牙,我以为直接上台操作呢,就跟体检一样。然而并没有,只是张嘴简单看了下,然后就给我开单子去拍片了。

心想:果然还是这个套路,不由得就想起,上次预约拍片,等待拿片的那个过程。没准一个上午就过去,算了,来都来了,原本就是抱着「今天啥也干不了的」心态来的。

到放射科拍片,再次被这超高的效率折服,我暗自算了一下,大概 3 分钟一个,我一篇公众号文章都没有看完,就到我了,进去我才知道怎么回事。

原来这并非传统放射的那种大机器,而是 mini 型的,照片也是 mini 型的,拍完就出来了。看下图:(手掌大小)

算上我缴费拿号跑路,整个过程都不到 10 分钟就搞定了。

4.

告知基本情况之后,就是询问是否拔牙了,我说「拔吧」,不然我跑这么老远来干嘛。

躺在手术台上还是有点紧张的,毕竟除了体检,还没这么待过。不过还好,除了在我上颚打的那针麻药比较疼外,几乎没有其他感觉,非要说有,那就是嗓子咽口水不舒服。

上面为什么说可能是两名护士,因为面对我这个特殊情况(需要一次拔两颗),她们似乎没多大的信心。虽然我什么也看不见(面部蒙住了),但也知道,中间换了她们主任过来拔的,她们叫她老师。也有可能她们只是实习医生吧,话说回来,牙科似乎门槛并不高,因为外边到处都是私人牙科门诊。

主任过来,手法就是不一样,又是电钻,又是钳子的,由于麻药的关系,我只能感受到推动力,并没有疼痛感。最后一下,牙齿拔出来的时候,仅仅就是感觉,似乎什么东西松动了一下而已。

拔出来之后,主任就又交回这两名护士了,剩下就是一些清洗和包扎的工作了,完了之后,塞了两块棉球在伤口处,让我咬着大概 30 分钟。

麻药渐渐扩散,感觉半边脸都是肿的(其实并没有),我想,索性再待半个多小时吧,把棉球吐了再走。

走的时候,9 点 40 多。

总结

对于去医院看病,一直有心理阴影,总觉得低效套路麻烦。不过这次,倒是让我觉得很痛快(也很痛,麻药过后),痛快是因为快速解决了我的问题,看来不管多大的病,还是去大医院的好。

大(好)医院的好处:一是资源紧张,能尽快解决你的问题,绝对不拖拉,当然也不会存在乱开检查单子,或是让你多住几天院的问题;二是熟能生巧,就算是这里最一般的医生,每天接触的病人(症状)也都是小医院的好几倍,所谓见多识广,很多小医院觉得做不了的手术,可能对大医院来说,就是个小手术。

同时,大医院的流程也相对高效得多了,还是因为人多,资源紧张,只能依靠制度流程来提高效率,不然很容易就拥堵了。

我这次拔了两颗牙,从进医院到出来,总共不到 2 个小时(算上我逗留的那半小时),我认为算是高效的了。

另外,让我很放心,没有多余的担忧,因为在牙科医院拔牙,对于它们来说,这种操作肯定熟练得跟玩儿似的吧。

说了这么多,我的结论是:

  1. 能去大医院就不去小的
  2. 能去专科医院就不去综合的
  3. 能不去就不要去

完。

阅读更多

8 月份总结

这应该是写得最晚的月总结了,也不知道上一周都干了些什么,拖到现在,可能是内心在抵触:「8 月份你都干了些啥,还好意思写总结」。

也是,可能这点小事,跟内心所期待的比起来,真的是不值得一谈。

终归还是有一些收获的,写出来,也算是给内心一个交代:「你看,还是做了一些事情的」。

跑步

每周平均 2 次,本以为跑步频率下降了,会导致又回到起点(成绩下降),然而,似乎没有多大的影响,月底跑了一个 10 KM,一不小心成为了个人最佳成绩。

读书

原本计划是读完手中几本「思维类」书籍,然而却看了几本「技术类」书籍。

你看,计划总是赶不上变化,看着没有完成的清单,难免有一些失落,即便是做了一些类似的其他事情,只是没有按照原计划执行而已。

看来自己离财务自由心态,尚且还有很大的距离。

写作

8 月份写的内容还是挺多的,在第一周,突然有感而发,写了一篇「财务自由心态」的文章,于是,后面为了填坑,陆续又写了 3 篇。

看似胡乱发表意见,实则是自己这段时间经历的思考。tag: 财务自由

另外,从天津回来以后,花了一两周的时间,将小程序重新上线了,写了关于小程序产品设计与开发的一系列文章。

公众号上只放了关于「产品思路」的文章。所有文章都放在了 GitHub 上了,点击这里查看。

One More Thing

8 月份带着小宝出去了两趟,上旬去了天津,带着小宝去看海,下旬去了趟世园会。

这是我觉得最有意义的事情,很多人可能会觉得累,觉得折腾,而我认为,累是肯定的,却是值得的,折腾的人生才有意义。

带着小宝出去,并不是为了让她玩些什么,而是想让她尽早接触这个世界,尽早找到自己一生想要追求的梦想。

这样的旅行,以后会越来越多,最好的早教,应该是带她出去,让她自己去感受。

完。

阅读更多

如何做到财务自由的心态

这是财务自由心态的最后一篇文章,来谈谈如何去做到拥有这样的心态。

首先申明,我自己也远达不到这样的状态,只是这段时间,想得多了,较之以往,感觉有了很大的改变。

故在此分享出来,作为参考,你赞同与否,对于我来说,也没有太大的关系。

放下心中的目标

有时候觉得,目标这个东西,似乎有点可怕,给自己设定目标,像极了给自己设定边界,画个圈圈把自己框起来。

一年后,我做到 aaa,我要成为 bbb,这无形给自己很大的压力。这样的目标,它的意义何在?

前面我也有谈到,目标本身并不重要,重要的是每天的努力。按照自己喜欢的方式,坚持努力去做就好了。

或者退一步说,你怎么知道一年后,你不会做到 aaaaaa,又或者,你不会成为 ccc?努力终究会有回报,去相信自己坚持的力量。

通往成功的道路千万条,何必现在就选哪一条?

去掉所谓的完美主义

很长一段时间,总是给自己标榜一种所谓的「完美主义」标签。

  • 读一本书,总是希望从第一页开始,一字不落看到最后一页;
  • 写一篇文章,总是希望有明确的价值,完整的文章结构,甚至于严谨的行文逻辑;
  • 做一个产品,还只是概念阶段的时候,就想要完整的产品设计,规划路线图,甚至商业逻辑;
  • 坚持某件事情,总是希望一天不落就做下去,假如中间断了一天,就感觉「破罐子破摔」了;

然而现实情况是,很多压根就没有去「做」,都停留在「想」的阶段了。「完美主义」并没有带来完美的结果。相反,很多事情,反倒因为想得太多,做得太少,而失败。

假如一开始就想到事情的复杂性,困难性,那么,什么事情都不要做了,人活在世上,已经很不容易了。

完美主义,往往是逃避现实的借口。

读书,想看哪里就看哪里,关键是去读,而不是怎么读;写作,拿起笔(键盘)就去写(敲),而不是去想该写点什么;有想法了,立马就去实现,只有在做的过程中,才知道怎么去做。

随时从头开始的勇气

想做了就去做,当然前提要去做,光想没用。做错了没有关系,重新来过。

成功创业者,大多数都是连续创业者,连续是什么意思,连续意味着,之前有多次的失败。

认准一件事情,想要去干的时候,别害怕失败。这不是一句空话,它有两个前提:

第一个是,需要找到你认准的的那件事,很多人终其一生,也未必能找到自己认准的那件事。

另一个是,不要孤注一掷。许多所谓的成功学说,都告诉我们做什么事情,都要「全力以赴」。这是典型的毒鸡汤,给自己留有失败后,重新来过的余地,才是正确的选择。

做到这两点,就不会害怕失败了,剩下的,就只是去做了。

你可能会问,又没有目标,又不做周详的计划,万一做错了,怎么办?很简单呀,重新选个方向,接着做就行了,又有什么好担心的呢。

这不就是财务自由的心态吗。

好了,说到这里,关于财务自由心态的分享,就先告一段落。这也是我近期的一些体会和思考,不一定对,仅作参考。

完。


拖了一个月,终于把坑填完了。其实,这些内容早就准备好了,只是懒得整理而已。

另外,这段时间也在写另外一个系列的文章,也就是小程序的产品设计与开发,写了也将近有十来篇文章。

我将文章全部上传到 Github 上了,感兴趣的话,可以点击这里查看

阅读更多

纪念日产品分析 | 计算日子

接上篇,说到使用场景。什么场景下,会使用纪念日?或者说,什么日子,需要纪念功能?每周或者每月都要做的事情,需要纪念吗?节假日需要纪念日吗?

在我看来,需要纪念的日子,都是周期较长的非特殊日子。所以,通常都是纪念生日,结婚纪念日等。

如果每周都过的日子,或者是节假日,想必不用纪念,你也都能记住。

产品分析

例如纪念生日,其实是想知道,距离下一个生日,还剩下多少天?这里的目标日期是「下一个生日」,而不是某一个固定的日期,目标日期是变化的,也可以说是需要重复的。

这就是「Days Matter」在创建日期的时候,就让你选择是否重复的原因。如果选择重复,那么每过一个周期,自动更新目标日期,这样就总能计算出距离下一个目标日期,还剩下多少天;如果选择不重复,那么就是显示距离目标日期,已经过了多少天。

例如,我在添加自己生日的时候,如果选择重复,那么就会显示距离下一个生日还剩下 248 天;如果选择不重复,那么就会显示已经过了 11075 天。

这是很自然就能想到的实现方案,但总觉得很别扭,因为对于同一个纪念日,重复或者不重复,是两条不同的信息,需要用户添加两次。

另外,在添加日期的表单中,多了一个叫「重复」的字段,会让用户产生困惑,而增加了使用成本。纪念日就是过去的某一个重要日子,什么是重复不重复。

我认为,应该有更好的解决方案才对。于是,我在 App Store 上搜索「倒数日」,将下载量比较高的 App 都下载了下来,试用了一遍。

试用了将近 10 来款 APP,果不其然,他们的实现逻辑全部都和「Days Matter」一致,那就是,在表单中加入「重复」字段。

连重复这个名称,都懒得改一下,也是醉了。直接使用「纪念周期」都比「重复」要好得多。

我的方案

所谓纪念日,就是过去的某个特殊日期,在添加的时候,它并不存在重复不重复的说法。也就是说,在添加日期的表单中,「重复」或者「纪念周期」类似的字段,根本就不需要。

用户也不需要去思考,是否选择重复的问题。用户需要做的是,记下过去那个重要时刻的日期即可。

添加完成后,默认显示过了多少天,当用户需要知道,距离下一个日期还剩下多少天的时候,可以手动开启纪念功能。

把纪念功能放到添加纪念日期之后,而不是用「重复」字段,把一个纪念日,生生割裂成两个日期。

这种处理方式更加符合常识,把选择滞后处理,也提升了用户体验,同时,一个纪念日,就是一条信息,数据逻辑也更清晰。

你可能会说,这是精简了功能的缘故。如果我想要显示,每隔 18 天,35 天,125 天,就重复一次的纪念日,你这咋实现?上面那个方案,我就可以在「重复」字段里,选择 18 天,35 天,125 天进行重复,直接就可以实现了。

我也可以在开启纪念功能的时候,让你选择纪念周期,同样是可以实现的。但是,我首先需要考虑的是,有什么纪念日,需要每隔 18 天 ,或 35 天,或 125 天纪念一下?

还是回到最初说的那句话「功能全未必是好的解决方案」,再加一句「产品的使用场景很重要」。

完。

阅读更多

功能全未必是好的解决方案 | 计算日子

这是一个普通得不能再普通的需求,去各大 APP 商店,搜索「倒数日」,都能找出一堆类似的 APP。

计算日期的功能不是一个刚性需求,可有可无,没有的话,其实没有什么大碍,有的话,也挺好玩,稍微设计一下,也是一个不错的小工具。

基于这样的目的,我就做了「计算日子」这个小工具,另外,还简单做了个分享卡片,如下图所示。

需求分析

纪念日的需求一直都存在,最初,我一直使用的「Days Matter」这款 APP,用了好多年,每次换机都必装,虽然使用频率不高,但作为一个工具,也实现了它的价值。

字节加工厂小程序里「计算日子」这个小工具,并不是为了将「Days Matter」这个 APP 复制到微信小程序中,而是从中提取出,我最需要的功能。

这类 APP 虽说叫「倒数日」,其实就是计算日期,距离过去某个日期有多少天?距离未来某个日期有多少天?

它的作用就是纪念过去,提醒未来。例如:生日、结婚纪念日、高考还剩多少天等,这么一说,关键的功能点就比较清晰了。

简单来说就是:列表,表单(添加/修改),分享卡片,提醒功能。如下图所示:

进一步思考

完成上述的功能点,就实现了最基本的需求(计算日期)。添加一个标题,指定一个日期,就可以计算出距离现在的天数。

我老爸在试用的时候,我在一旁看着他,他把我老妈的出生日期、我的出生日期,以及他们的结婚纪念日,添加进去后,然后看着页面,很困惑的看着我,说道「为什么不显示生日还剩多少天?」

一下把我问懵了,页面上显示的,当然只有你添加的日期距离现在的天数呀,要是想显示还剩下多少天,那就得添加「下一个生日」的那个日期呀。

解释完,我就意识到问题所在了,这是产品的问题。「计算日期」的功能,在我看来就是冷冰冰的数字加减,你填入什么日期,后台计算出距离现在的天数,显示给你,你想要显示生日还剩多少天,就不是填出生日期,而是填写「下一个生日」的那个日期。

比如,我是 1989 年 5 月 3 日 出生,那么想显示我的生日还剩多少天,应该保存 2020 年 5 月 3 日,这样才对。当然过了一年,还得再保存一次。

这个操作就有点不友好了,那该怎么实现呢?

Days Matter 解决方案

下图是「Days Matter」这款 APP 的添加页面。

它的实现方式是在表单中加入「重复」这个字段,而且重复的选项很多,非常全面。

如上图,分成两栏,左边「每x」一直到了「每999」,右边分为天、周、月以及年。所以,重复周期的跨度,从每天一直到了每 999 年,当然中间会有很多重复的,例如:每 7 天 = 每周。

在我看来,这是典型的程序员思维,不管什么使用场景,我提供最全的功能,用户总能找到想要的。

而产品思维是,在做每一个功能之前,都要去想,这个功能的实际使用场景是怎样的。

从某种角度来说,功能全,未必是好的解决方案。因为提供最全的功能,意味着,你并不知道用户最想要的。

我设计了一个新的解决方案(当然也未必是好的)。由于线上版本还在审核中,姑且放到下一篇再讲吧。

未完。

阅读更多