最近收获与反思

大家好,我是光源。

不知不觉已经 6 月份,计划年初要完成的事还未完成「年初」就已过去。自年后以来工作上投入度非常高,失去了几乎所有业余时间但也收获了一些认可,算是在新环境新工作里稳定下来(距离去年入职时间也过去半年多了,谈不上「新」工作了,哈哈)。

在这段时间里有一些新的思考,记录成此文。

最近正是高考。我们年少时应该都有过这样的幻想:假如我们当初有 xx 那么勤奋我们肯定能考上更好的大学、假如我们在高中时不贪玩一定能考得更好…… 但年岁渐长,我们渐渐懂得很多事重来多少次都是一样,我们的认知、我们的习惯、我们的性格、我们处理事情的方式决定了我们那一刻只会做出同一种选择。

内向者很难变得口若悬河活跃外放,好动者很难学会心无旁骛地应对枯燥的练习,怯懦者很难从容应对各种挑战。

时间给我们以智慧,让我们渐渐懂得自己能做什么和不能做什么。当然,有大毅力者绝对可以通过科学的方法和大量的练习突破自身的桎梏,但对于普通人而言,认清自己能力范围、与自己的优势劣势和谐相处并非是坏事

回到我自身,因为去年 10 月底更换了工作平台,这半年来一直在调整使用时间和精力的方式期望能符合我自己的生活节奏。所得的收获是,在没有保证足够休息时间的前提下,我的精力并不足以在工作之余做其他事。

以前给自己定计划时总把工作之外的时间排得满满的,虽然「仁慈地」排了半个小时中途休息时间,但实践下来,工作之后就算有时间也无剩余的精力去使用起来。

接受自己不是超人吧,我对自己说。

抱怨并没有什么用,当初接受这个 offer 时就已经做好足够的心理建设,且工作是真的忙并不是磨洋工。

我可以做的是如何是适应环境并超脱这个环境。(说起来还有点小兴奋?)

可以从两个方向做优化,时间和精力。

是时候再刷一遍《哈佛幸福课》

大家好,我是光源。

不知道何时起「幸福」和「快乐」这些美好的词汇逐渐离我们远去,生活的周遭充斥着各种各样负面的信息:房价高负担好重、某某公司又裁员了、每天工作好久好累、养孩子压力大每天都好焦虑…… 当我们打开脉脉、打开微博、打开论坛,各种焦虑简直要把我们吞没。

人无远虑必有近忧,为当下和未来担忧固然是没错,但生活不能这样下去,在阳光灿烂的日子里还是希望能露出笑容。

就在我思索如何去改变时,突然想起好几年前看过的一个公开课《哈佛大学公开课:幸福课》,尽管细节已经忘记,但是看视频时的那种内心平静感却记忆下来。我想,是时候再刷一遍了。

这门公开课是讲什么的?

顾名思义,它主要围绕着「幸福」这个词展开。

我们来到这个世上,到底追求什么才是最重要的?塔尔博士(教授这门课的讲师)认为幸福感是衡量人生的唯一标准,是所有目标的最终目标。

「幸福」并不玄乎,它属于积极心理学的范畴,可以用科学的方式去研究。公开课中塔尔博士像一个老朋友一样将自己的经历和观点娓娓道来,引用的资料都有权威的研究和论文作为依据。

那么它是用来给我们加油打气的鸡汤么?当然不是。鸡汤之所以被称之为鸡汤,是因为鸡汤只有鼓舞士气的作用而无具体实操的指导,只能给我们在心理上做一次短暂的按摩其实没有卵用。

而幸福课是可以实操的。它告诉我们睡眠和爱情的重要性、如何去解决负面情绪、如何面对压力、如何让爱情天长地久等等 —— 我觉得是在教我们如何好好地生活

我特别喜欢这门课的场景布置,很像 TED 的演讲会场,黑暗的背景下一个不刺眼的舞台,讲师像冥想老师一样给你安静的力量,你会不知不觉放松下来听他讲述。

有几点让我特别有共鸣(以至于让我在几年后的现在还记得)。

第一是运动对情绪的重要性。当身边有朋友情绪不好或身体不好时我总会建议他们去运动下,特别是互联网行业,有时候运动对坐了一天椅子的身体也是一种释放。对于我个人而言,运动更是一种良药,不管生理上还有心理上都给我很多力量。当然我的感悟不够有依据,公开课中讲师是分享了相当多的资料并给出如何运动的建议。

第二是冥想。几年前看完公开课后我曾经一度迷上冥想,各种找冥想的书看。而大家熟知的乔布斯也是冥想的爱好者。虽然我始终不得要领最后放弃,但冥想的益处我是想当认可的。

第三是触摸、爱情和睡眠的重要性。脱离「触摸皮肤」这个限定,简单的拥抱、握手都是有益的,都能给我们力量。而睡眠则不必多说,身体和精神并不是分离的两个东西,身体不好会导致精神萎靡,精神差则身体也会出现各种病痛。

第四是完美主义。「完美主义」这点感触太深了。曾经很多次我尝试自己去做一个应用,结果在设计交互和视觉时就各种万般纠结最后甚至开始怀疑 idea 本身是否值得去做 —— 每每如此我总是叹息,「该死的完美主义」!

还有其他东西已然忘却。

写到这里,我忽然有一个念头,那就是虽然我不记得幸福课的一些细节,但它对我却影响至今。比如对运动、睡眠、爱情的看法(惭愧的是明知晚睡不好却没能坚持早睡早起)。

毕业后的几年,明显感觉压力大了焦虑多了,幸好我还有这剂良药。

这也是我推荐给大家的目的吧。

准备再刷一遍哈佛幸福课,为了防止忘记细节,这次可能会边看边记录一些笔记。《哈佛大学公开课:幸福课》在网易公开课里可以看到,每一集都非常长,假如有朋友看不下去视频的,可以后面直接看我的笔记。

非常欢迎有同好可以交流下。

小谈 Kotlin 的空处理

大家好,我是光源。

近来关于 Kotlin 的文章着实不少,Google 官方的支持让越来越多的开发者开始关注 Kotlin。不久前加入的项目用的是 Kotlin 与 Java 混合开发的模式,纸上得来终觉浅,终于可以实践一把新语言。本文就来小谈一下 Kotlin 中的空处理。

一、上手的确容易

先扯一扯 Kotlin 学习本身。

之前各种听人说上手容易,但真要切换到另一门语言,难免还是会踌躇是否有这个必要。现在因为工作关系直接上手 Kotlin,感受是 真香(上手的确容易)

首先在代码阅读层面,对于有 Java 基础的程序员来说阅读 Kotlin 代码基本无障碍,除去一些操作符、一些顺序上的变化,整体上可以直接阅读。

其次在代码编写层面,仅需要改变一些编码习惯。主要是:语句不要写分号、变量需要用 var 或 val 声明、类型写在变量之后、实例化一个对象时不用 “new” …… 习惯层面的改变只需要多写代码,自然而然就适应了。

最后在学习方式层面,由于 Kotlin 最终都会被编译成字节码跑在 JVM 上,所以初入手时完全可以用 Java 作为对比。比如你可能不知道 Kotlin 里 companion object 是什么意思,但你知道既然 Kotlin 最终会转成 jvm 可以跑的字节码,那 Java 里必然可以找到与之对应的东西。

Android Studio 也提供了很方便的工具。选择菜单 Tools -> Kotlin -> Show Kotlin Bytecode 即可看到 Kotlin 编译成的字节码,点击窗口上方的 “Decompile” 即可看到这份字节码对应的 Java 代码。 —— 这个工具特别重要,假如一段 Kotlin 代码让你看得云里雾里,看一下它对应的 Java 代码你就能知道它的含义。

当然这里仅仅是说上手或入门(仅入门的话可以忽略诸如协程等高级特性),真正熟练应用乃至完全掌握肯定需要一定时间。

二、针对 NPE 的强规则

有些文章说 Kotlin 帮开发者解决了 NPE(NullPointerException),这个说法是不对的。在我看来,Kotlin 没有帮开发者解决了 NPE (Kotlin: 臣妾真的做不到啊),而是通过在语言层面增加各种强规则,强制开发者去自己处理可能的空指针问题,达到尽量减少(只能减少而无法完全避免)出现 NPE 的目的。

那么 Kotlin 具体是怎么做的呢?别着急,我们可以先回顾一下在 Java 中我们是怎么处理空指针问题的。

Java 中对于空指针的处理总体来说可以分为“防御式编程”和“契约式编程”两种方案。

最新靠谱可用的 Mac 环境下 FFmpeg 环境搭建

大家好,我是光源。

最近在尝试搭建 FFmpeg 开发环境时遇到一个蛋疼的事,Google 了 N 篇文章竟然没有一篇是可以跑起来的!

少部分教程是给出了自我矛盾的配置(是的,按照贴出来的代码和配置,他自己都跑不起来),大部分教程是看着挺全但忽略了某几个关键的点导致跑不起来,更蛋疼的是碰到报错后错误相关的文章也很少,当然还有一些是年代久远过时了。

于是在成功跑起来后,我将整个搭建过程整理出来,希望可以帮到后面的人。

本文基于 Mac OS X + Android Studio 3.2 + FFmpeg 3.3 + CMake。

文章会分为两部分,第一部分是总结一下碰到的几个坑,这样只是因为报错而无法继续的朋友可以先看看是否可以解决问题;第二部分是搭建过程的完整描述(我特意用另一台电脑测试过,可以完美跑起来)。

一、FFmpeg 搭建的常见问题

1. NDK 的问题

在编译之前,教程都会让我们修改命令中 NDK 的地址为自己本地的地址,我们当然自然而然地改成了 Android Studio 自带的 ndk-bundle。

然后编译的时候就发现会出现errno.h: No such file or directory字样的error。

这是因为 Android Studio 自带的 NDK 缺少相关的 .h 文件,从网上额外下载 NDK 然后编译时使用就可以解决问题。(基于 FFmpeg 3.3)

2. 编译命令的问题

报错信息形如

1
2
3
ffmpeg_build.sh: line 14: ./configure: No such file or directory

ffmpeg_build.sh: line 20: --extra-cflags=-Os -fpic -marm: command not found

之类的,请检查一下 Android 编辑脚本的 “/” 后是否有空格。

由于不同系统存在差异,最好找对应系统下他人验证可行的编译命令。

3. 编译相关的版本

编译过程有 NDK 版本、Android 版本、FFmpeg 版本、Android Studio 版本等,不同版本存在差异,最好是完全使用教程描述时的版本。

比如编译命令中包含的 Android 版本

1
export SYSROOT=$NDK/platforms/android-21/arch-arm/

这里的 android-21 改成 26 就不行,因为搜索了这两个文件夹只有 21 中有需要的 .h 文件。

如何做好技术调研

大家好,我是光源。

近日一直在思考一个问题,到底怎样做才算是完整且优秀得完成一次技术调研。

我曾经以实习生的身份做过糟糕或让老大称赞的技术调研;也以正式员工的身份独自负责过技术调研工作(意味着不用向谁汇报,直接进项目);也以导师身份分配技术调研工作给新人,看着几个新人经历着我之前的遭遇,他中有完成得漂漂亮亮的,也有完成得不够好的;最后也旁观过优秀的同事做过技术调研。

教技术的书籍很多,但是教做事的书籍很少——即使有也不会教那么细。我曾因这类工作而彷徨、受挫,现在又看着新人彷徨、受挫,于是就有了想法尝试总结一个范式出来。

因此下文会从个人的一些出发做一些总结和思考,与各位读者分享。当然作为追寻最佳实践的我而言,更欢迎能互相讨论以完善我的观点。因能力有限,如果有不妥或者补充的地方,还请联系我(微信公众号:guangyuan_coder),十分期待与你的交流。

一、了解需求

除去自己发起的技术调研,其他技术调研都需要先了解需求。估计很多人看到这个就会心想,切,这个谁都知道啊。

是的,“了解需求”这是个人尽皆知且每个人在技术调研前都会去做的一件事。但不夸张地说,在这个阶段栽跟头的人最多。

很多人,特别是新人,在这个阶段出问题的普遍原因大概有以下几点:

  • 作为新人畏畏缩缩,担心一开始问太多会显得自己很无知,担心对方轻视自己
  • 听到几个关键字就以为了解需求,没有在意对方说的一些细节
  • 对需求有疑惑的情况下硬着头皮做,缺乏沟通意识
  • 没有分阶段跟需求方沟通,可能在快完成了发现需求理解错误要推倒重做

诸如此类。

解决方案也很简单,咱们把问题一一解决。

首先是接到需求时,认真听对方讲,对对方所讲内容有疑惑的是可以在对方讲完后提问的。千万不要听的时候是懂非懂,想着待会私底下自己查(当然提问也要有技巧,这个自己琢磨去)。

然后假如不了解的东西太多(例如一上来就给新人分配一个陌生业务模块的任务,的确会一脸懵逼),又不想围着需求方各种打扰,完全可以请教下熟悉相应模块的同事嘛。

最后,假如是复杂的需求,可以在做的过程中,分步跟需求方确认,这个下文会展开。

这里举个例子:

一天,小明正热火朝天地写着代码,突然肩膀被人一拍,回头一看老大正站在背后。

小明,这有个调研工作你去做一下?

没问题,具体是做什么呢?

是这样,我们需要做一个 A 功能以支撑 B 模块,这块功能 iOS 端已经完成,可以与他们讨论下。

好的,没问题。

于是小明屁颠屁颠开始调研 A 功能是怎么实现,耗费了几天时间后,老大过来一看,诶,你这实现不是我想要的呀。

原来虽然小明选取的技术方案是业界知名的 A 功能实现方案,但却没法用到 B 模块上。而且需求隐含的意思是,既然 iOS 端已经实现了,需求的具体情况可以去询问 iOS 端对应开发。

二、进行调研

在做好需求了解的前提下,调研本身会显得轻松点。

需要注意的是,进行调研时要合理安排时间,调研过程往往伴随着对新知的探索,很容易“沉迷于学习”。别忘了这是一项工作。(当然不只是技术调研在日常工作中也一样,要学会合理安排时间,注意时间成本)

个人有个小技巧,按照以下步骤来做往往效果不错:

  1. 尽量多得收集各种方案和资料
  2. 迅速粗略得过一遍,大体上总结出几种可能合适的方案
  3. 针对几种方案,一边分别调研每种方案,一边做笔记
  4. 最后拿着笔记做最后的横向对比
  5. 得出结论,同时因为做了笔记,反馈的素材也有了

以上是关于“如何做”的。需要说明的是这只是我的个人习惯,你有自己的做事风格更好,没必要强行一致。

还有一点需要注意的是,千万不要埋头苦干

“沟通”应该是贯穿始终的一件事,在上文也提到了,对需求的理解偏差可能会导致整个调研工作推倒重来。

那么该如何沟通,以及沟通些什么呢?

第一个问题,如何沟通。我的方案是,阶段性得去跟需求方或者跟有经验的同事讨论。比如一个技术调研有四个阶段,那每完成一个小阶段,就可以尝试去沟通一次(必须强调下,规则是死的人是活的。假如对方很忙的情况下,你偏要强行打扰对方去沟通;或者一个很小的技术调研你也按阶段多次去沟通,就尴尬了)。

第二个问题,沟通的内容,我认为主要有以下几点:

  • 对需求的细节的分别确认
  • 将自己的工作进度汇报给对方(这点很重要,一方面是让对方知道你在做什么及完成到哪个阶段,另一方面是假如你路走偏了,对方能及时知道并纠正)
  • 将自己当前的工作成果告知对方

做到以上几点,应该就差不多了。下面说说第三阶段,结果验收。

三、反馈

做完技术调研后,一定要有成果。

可以是调研之后发现“某个方案是最佳的”,也可以调研之后发现“尚无解决方案”,还可以调研后对需求本身提出质疑,但一定不能做着做着无声无息得做没了(不是所有技术调研都有需求方催促或跟进)。

反馈的展现形式根据需求来,有几种常见的展现形式:

  • 假如是比较大的技术调研可以做一些分享的可以用 PPT 的形式展现出来。比如有同事调研 “兼容 Android 6.0 权限管理”,用一个 PPT 将技术方案的选择、6.0 权限管理的原理、最终方案的选取等分享出来就特别好
  • 假如是简单的技术调研可以以文档的形式展现,推荐用 markdown 来写,github/gitlab 可以直接展示,很方便
  • 再简单点则是以邮件或口头的形式反馈

个人比较推荐以文档的形式,大部分调研工作都很适合。

反馈的内容有几点是需要考虑写进去的:

  • 简要说明下调研需求
  • 介绍下跟需求相关的前置知识
  • 目前有哪些方案,具体分析下各个方案的优缺点及适合的场景
  • 技术调研的结果是怎样,不可行的话是因为什么,可行的话说说最终决定使用何种方案(自己无法决定的话可以弄个分享讨论会),并说说该方案跟其他方案比有何优势
  • 假如是新库的引进,需要简要介绍下该库的使用及内部原理
  • 调研过程中碰到了哪些问题,如何解决
  • 另外,假如时间允许,可以考虑把反馈当成分享来做,系统介绍下相关的知识——这个比较适合 PPT 的形式

大概是这些,总而言之,把一次技术调研当成一次绝佳的学习机会来做,那反馈的内容就不会显得空洞。

反馈的时机的话,在保证质量的前提下,尽量主动、提前向需求方或组内其他同事提出。一方面是你的反馈对别人而言也是一个学习机会,另一方面主动推送一件事也是一个优秀的表现。

写在最后

以上是一点个人浅见,必须要说明的一点是,本人能力有限见识浅薄,上文的一些观点不一定正确。各位看官切不可太过信赖,还是要有自己的思考为妙。

另外,写到最后,发现跟“技术调研”中的“技术”倒关联不大了,哈哈。我也就不纠结这个了。

最后,我写博客的目的就是希望将个人的观点、观念摆出来让读者评价或吐槽,因此假如觉得有不妥或者可优化的地方,还请不吝赐教。

Fork me on GitHub