Here's to Change

请问你真的有在努力吗 ?

0%

前言

刚开始接触 Go 的时候,被 Go 这种可以直接返回多个变量的设计惊呆了,而且错误也是作为变量与函数结果一并返回。在此之前接触的都是 Java 或者 Kotlin 这种只有一个返回值的语言,而这两种语言本身的错误处理机制都是在函数签名上抛出一个异常,由方法调用方决定是否要处理该异常。Java 中所有的异常都继承自 java.lang.Throwable 接口,然后又分为 Error 和 Exception 两个分支,其中 Error 表示不该由程序处理的错误,通常由虚拟机抛出;而 Exception 又继续分为检查异常和不受检查异常。检查异常必须显式处理,否则编译器无法编译通过,不受检查异常就可以选择性是否进行处理。

Read more »

这篇文章其实是前几天我一个学妹为了完成在校一门职业发展课程的作业,邀请我作为毕业学长的一次小小的访谈,我稍微整理了一下,就有了此文。同时也是难得自己回顾反思下,是否做到了知行合一。

Read more »

刚开始写 go,因为用习惯了 JetBrains 系列的 IDE,所以还是选择用 GoLand 来做 Go 开发。 GoLand 本身相当强大,不过有一点确实比不了 VS code,就是默认没有 golint 的支持,需要用户手动配置和开启。

Read more »

前言

如果说我的 2019 年要用一个词来形如,我给自己的是:废柴。是的,这一年我几乎一事无成,做什么什么半途而废,就连 2018 年的总结也懒得没写。其实本来我也没打算写 2019 年总结的,不过昨晚看了某个关注的博主写的年度总结,写的真好啊,这一年里发生的大事小事,开心的不开心都写了出来,分门别类的也很清晰,同时还贴了数百张图来记录,这样的总结就非常有意义啊。于是也动了继续写年度总结的想法,所以还得感谢这位博主 提拉拉拉就是技术宅

为了能总结得更有条理,我会把过去这一年分成几个方面来分别回顾(其实就是模仿那位博主),不知道我在一个个回顾的时候会不会内牛满面,悔恨不已啊 😂。

Read more »

fragment 的碎碎念

GraphQL 大家都不再陌生了,很多技术前瞻(作死)的公司都在用了,其中 fragment 作为一个 feature 我觉得很有必要单独拿出来说道说道。GraphQL 作为一种查询语言,从 OOP 的思想来看,fragment 可以看作是这个语言的 class ,也就是对一个具有相同属性的对象的定义。然后就可以多处引用,而无需多次编写。一个基本的 fragment 用起来形如下:

Read more »

作为一名程序员,肯定对极客这个词不会陌生。很多人标榜自己具有极客精神,但是观察他们的说话方式,行事风格,其实是与极客精神相去甚远的。但这可能也不能怪他们,也许很多人并不真的了解极客一词的内涵。

极客,又译为技客、奇客,是英文单词 geek 的音译兼义译。原本的俚语是指反常的人。
这个词在“美国俚语”中意指智力超群,善于钻研但不爱社交的学者或知识分子,含有贬义,因为极客常常醉心于自己感兴趣的领域,可以牺牲个人卫生,社交技巧或社会地位(但并不是所有的geek都会这么做)。但近年来,随着互联网文化兴起,其贬义的成分正慢慢减少。
但这个词仍保留拥有超群的智力和努力的本意,又通常被用于形容对计算机和网络技术有狂热兴趣并投入大量时间钻研的人。所以俗称发烧友或怪杰。如计算机怪杰(Computer Geek),技术/科技怪杰(Techno-geek),玩家怪杰(gamer geek)等。
———— 源自维基百科

我对极客的理解非常简单:追求极致。

Read more »

我是一名软件开发人员,工作一年多,技术还处于初级水平吧,虽然完成日常开发任务问题不大,收入勉强过得去,在上海这个城市倒也还能养活自己,衣食也算无忧,但总觉得少了点什么。

Read more »

接触 MVP 已经很久了,但我觉得我还没有真正掌握它。它总是在不经意间给我带来意想不到的。。惊,没有喜。最早接触 MVP 是在哪里早就已经忘记了 ,只是依稀还记得对 MVP 的理解与使用经过了好几个时期。

Read more »

很多 App 都会要求输入的字符种类、长度有所限制,在此之前我其实已经遇到了这样的需求,只能输入中文和英文,并且不同的语言所限制的长度不同。那个时候会觉得这样的限制比较麻烦,因为总认为涉及到中文的判断就比较麻烦,所以推脱说实现比较麻烦没有太多的时间,就给暂时压了下来。直到第二次遇到这样的需求我直到没办法再退了,结果 google 了下发现判断中文也没那么麻烦,使用正则判断中文字符范围即可。

Read more »

为什么这么做:公司的 jenkins 是搭建在阿里云上的,处于外网,但是 jenkins 服务器本身配置较低,最开始只是为了服务端自动化构建搭建起来,后来配置 Android 打包后就一直处于性能不够的情况,频繁打包失败,甚至会导致服务器直接卡死,影响其他的项目构建,就这还是在服务器从 1 核 2G 升到了 1 核 4G 的条件下了。但是为了 Android 打包继续增加服务器的配置,明显是不划算的。正好公司的文件共享主机性能不错,4 核 16G,用来打包绰绰有余。一开始计划在内网机器上也配置 jenkins ,但这种方式 gitlab 的 webhook 貌似没办法调到位于内网的 jenkins ,即使做了内网穿透也无济于事,具体原因不明。后来在搜索中看到了这篇博文:远端GitLab+Jenkins(CentOS)+本地Mac 做CI自动打包iOS上传到蒲公英, 受到启发,也决定通过配置内网节点的方式来做。

Read more »