袁钰涵

袁钰涵 查看完整档案

北京编辑  |  填写毕业院校  |  填写所在公司/组织 segmentfault.com/u/yuanhan_5f5f19f9dabdc 编辑
编辑

而受苦又是一个坏习惯

个人动态

袁钰涵 发布了文章 · 10月30日

思否有约 | @陈大鱼头 :要是能重来,我还是会选这条充满着内卷和996的路

本期访谈嘉宾:@陈大鱼头
访谈编辑:袁钰涵

鱼头从2016年就开始使用思否社区,可以说是我们的老用户了,思否陪他走过了从提问者到回答者再到如今作者的历程,成为了他程序猿生涯中的一部分。

当问到鱼头如何走上程序猿这条“脱发”之路时,鱼头高兴地说,从朋友教他在网页中敲出 “ hello world ” 的那天起,他就一头闯入了这个关于编程的世界了。鱼头还说,如果能重来,他还是会选择这个充满着 996 和内卷的行业,因为在这个地方,只要实力够强,就一定能成功。

Q:要来和大家做个自我介绍吗?

哈哈哈,哈喽,大家好!我是鱼头,别人一般喊我深圳金城武,距离十八岁还有 -7 年,一枚酷爱广场舞的黑暗料理界新星,间歇性运动,持续性暴饮暴食,性别男,爱好写代码。

Po 一张实验室的工作照

Q:现在在从事什么工作呢?常用的技术栈是什么?

现在是一名前端工程师,常用的技术栈有:前端标配 + 常见库/框架 + docker + jenkins + python,平时最常用的工具是:vscode + postman + typora,这里也给大家推荐了一款插件,是 vscode 的 comment translate,它能通过鼠标移动实时进行翻译,用起来真的很 nice,安利安利 。

Q:工作之中有哪个瞬间让你觉得很有成就感?

最有成就感的大概是在老东家独立开发的专利项目「代码转换的方法及装置」,这是一个实现了javascript python blockly(可视化拖拽代码生成库)互相转换的纯runtime的定向编译器,不开源,专利地址:http://www.soopat.com/Patent/...

在完成这个专利项目的过程中,不仅仅收获了成就感,个人也得到了提升。比如在接手的那一刻,感觉开发角色转变了,虽然都是搬砖的,但从业务仔转变为了底层库的开发者(这个专利项目核心的js库我给它起名ebt.js,目前真的实现了这个功能并且上线卖的,应该只有 bbc 的 microbit )。其次是有天无意中看到同行花了好几千来找人实现一个我的 ebt.js 里已经实现的数据处理算法时,真的感觉自己不一样了。

Q:工作中又有哪个瞬间让你“怀疑人生”?

怀疑人生的话,在稿定,也就是新东家工作的每一天都怀疑人生,因为在以前的工作单位都是单兵作战,没有什么团队协作的经验,会形成一些不太好的开发习惯,在新工作中不断地暴露,目前正在改正中,会比较难受。

Q:刚开始团队合作时大概是出现了什么碰撞?如何适应过来的?

问题主要是出在 git 操作规范跟编码规范上,以前 git 就是 add commit push 一波流,但现在无论是解决 bug,写迭代都需要考虑 commit 信息以及任务分支代码合并到环境分支上时会不会影响后续同事的操作,编码也得更加考虑复用性,是否有利于团队协作,不像以前,规范就一个人定。

当然我也在不断的适应新环境,在这个过程中,领导会经常 review 我的代码,觉得不合理的地方会和我说,有时候我也会根据同事的反馈去调整习惯。我们团队都挺 nice 的,也会互相帮忙,大家关系都挺好的,大概是因为经常一起加班吧,哈哈。

虽然会压力很大,但也知道这是一个成长的过程,还是很开心的接受了这些压力,平时也会通过做运动,喝奶茶,闲逛,谈恋爱来释放压力。(最后一条喂了小编一波狗粮)

Q:平时生活习惯是怎么样的呢?

开始工作前会习惯性地先点杯咖啡,拿铁喝热的,美式喝冰的,然后一坐一整天。

个人爱好有:做菜、闲逛、跑步、撸铁。

关于跑步这件事,以前是间歇性运动,持续性暴饮暴食,现在都没时间运动了,开始有点过劳肥了。做菜还是有在做的,擅长于煲汤和做甜品,对于粤菜也基本是信手拈来。

随手附上一张家乡特色菜(大家猜到鱼头是哪里人了吗)

下图鱼头亲手做的蓝牙音响,耗时两个晚上,是他追求女朋友时精心准备的生日礼物(冷冷的狗粮在小编脸上胡乱拍打)

Q:处于二十五岁,怎么看自己的状态?

不会觉得自己不行,也不会觉得自己有多优秀,时刻虚心,时刻向上,这是一个专注于自我纵向比较的时期。对于自己所选的行业,只要还没被淘汰就会做下去,我是一个脸皮比较厚的人,就算做得不好,被人嘲笑,我也都不 care,喜欢就去做,不想那么多。

Q:如何看待国内社区的环境和氛围

国内的前端社区比较浮躁。很多新人就把视野关注在基础面经之上,以前就是轮播图,游戏,如今就是闭包,框架,以及 github 的 star。他们都不愿意耐住性子去学习基础,短期看来能帮助他们找到一份合适的工作,但如果不跳出舒适区和这种面经思维,终究是走不远。

这里也希望社区里的各位大佬可以对新人的学习方式进行多样式的引导,而不仅仅是面经。

Q:鱼头对编程初学者和怀抱梦想的年轻人有没有什么建议?

想就去做吧,耐住寂寞脚踏实地的走,不要跟别人横行比较,关注自己的纵向发展,编程比起其他行业最大的优势就是公平,虽然社区经常吐槽996,内卷什么的,但是只要你够强,就一定能成功。

Q:最后鱼头对未来有什么期待吗?

编程和甜品都是我很喜欢的东西,我在想未来能不能把他们结合在一起,开个编程甜品店什么的,感觉这样还挺美好的。别看我是个程序猿,其实我是一个话很多的人,开甜品店的话大概会有更多与人交流的机会吧。

Q:作为一个话很多的人,做编程会不会有点寂寞?

嗯,偶尔会和同事聊聊天吧,但我已经把电脑当成另一半了,敲代码的时候就像在和它对话。

Q:就像敲下 “hello world”?

哈哈哈哈,是的,从那天起我开始和它对话了。

小编有话说:

小编曾问鱼头在工作中,有没有一些时刻会感觉这份工作很适合自己,鱼头说他没有特别去注意这一点。像每一份工作一样,前端也会为他带来好的情绪与坏的情绪,他会有成就感也会有挫败感,但当他敲下单词进行不同组合时,那些意想不到的效果让他着迷,凭着这份着迷,他愿意在这里坚持下去。

所以当我们对前途感到迷茫时,不如就选定一个喜欢的方向,然后定在那里,坚持、扎根,未来的事情让未来去说,我们做好现在就行。


欢迎有兴趣参与访谈的小伙伴踊跃报名,《思否有约》将把你与编程有关的故事记录下来。报名邮箱:mango@sifou.com
image.png

查看原文

赞 7 收藏 0 评论 4

袁钰涵 赞了文章 · 10月30日

1024好物分享丨脱单不脱发,就靠它!

image
image
image
image
image
image

代码千万条,发量第一位。
防治不规范,出门两行泪。
修BUG不易,守发际线更难。

那么问题来了,程序员的脱发,是不是不可复制,但有迹可循呢?


加班成常态,长期对着电脑,久而久之就更容易脱发?其实,屏幕本身没问题,而是屏幕发出的蓝光才是影响睡眠,导致脱发的罪魁祸首。

短波长蓝光是波长在400nm-500nm(纳米)的高能量可见光,蓝光普遍存在于电脑、电影屏幕、手机中等。
image

近年来,已有不少研究已经证实电脑屏幕中发出的短波长蓝光会影响我们的睡眠质量。

人脑部深处,有一个像松果般大小的“松果体”,它分泌出来的激素,叫褪黑素,它在调整人体的昼夜节律方面发挥着重要作用。波长450~500纳米的蓝光会抑制褪黑素的产生。

褪黑素会通过对神经内分泌系统、神经递质及其受体、视交叉上核、体温以及神经免疫网络的作用,来参与睡眠的调节,褪黑素与我们的睡眠质量有着密不可分的关系。

毛囊中含有褪黑素受体,通过化学反应,褪黑素会对抗雄性激素的作用—也就是延长毛囊的老化期,从而增加头发的数量并防止脱发。

褪黑素可以保护头皮和毛囊免受导致脱发的炎症和组织的损伤。
image

经常面对电脑加班到深夜,影响褪黑素分泌,睡眠和头皮问题可不就接踵而来了么?

用脑过度就会脱发?


改不完的Bug,对不完的需求,让程序员还承受着高强度的工作压力。

在电脑前长时间工作很容易精神疲劳, 使中枢神经系统长期处于紧张状态,头皮局部的血管收缩使供血量减少, 造成毛囊营养不良。

脑力劳动过量就会脱发吗?其实是精神压力让你更“头冷”。

长时间紧张会导致大脑血液循环也加快,血液中的氧气等成分优先被大脑使用,“分给”的部分就变少了,脱发问题就来了:

毛乳头是由各种毛囊构成的。这是负责头发生长的部分,位于毛囊的最底部:
毛囊和毛乳头需要足够的氧气才能存活

毛乳头的重要作用之一就是它与头皮的毛细血管相连。它们把血液输送到毛囊,毛囊又输送氧气和重要的营养物质。

毛乳头细胞可以将这些重要的成分传递到毛囊的其他部位。但是当血液供应减少,甚至完全切断时会发生什么呢?

image

由于DHT(雄激素二氢睾酮)在毛囊中的存在,会产生炎症和刺激。

而伴随着炎症的加剧,毛乳头与毛细血管的连接被切断。这种情况首先发生得很慢,因此只有一些血液流动是可能的,但很快就会转变为完全缺乏血液供应。

当这种情况发生时,毛囊无法自我维持并死亡。头发自然没办法健康生长。说回到程序员的工作强度与压力:
image
压力越大,摄入的氧气就越少。这可能是由于体力活动减少,或者浅呼吸增加,同时深呼吸减少。不管是什么原因,氧气的减少都会对毛囊产生负面影响。

保持毛囊的良好循环是至关重要的,这样营养、氧气和激素可以促进生长。否则头发生存的环境质量发生改变,脱发就找上了门。

好物推荐


随着工作压力和脱发之间的联系越来越清晰,重要的是要确保你在适当地做出一些改变。
image
在生活上做出一些尝试和改变,选择时光里,哪怕再忙,也要悉心呵护头发。Menxlab时光里时光里专为各类有头皮发质问题的人群研发,主打防脱育发和头皮抗衰,为头皮健康全方位进行保护,贴心守护你的发际线。

1024程序员节,Menxlab时光里特别推出关爱头部力量活动。关爱我们头顶最亲密的朋友,现在添加蔓博士即可免费体验头皮检测,为你解答各种头皮困扰:

image

脱发是常态,但防脱不也是常态吗?不论工作有多忙,请把烦恼交给我们,你只管努力,时光里能量还你帅气人生。

查看原文

赞 16 收藏 0 评论 0

袁钰涵 发布了文章 · 10月27日

Facebook 将推出云游戏服务,此服务无法在 iOS 系统应用

image.png

10 月 26 号 Facebook 宣布在其官站和 Android 系统上的 APP 推出云游戏服务,云游戏能让用户可以在短时间内不跳转页面免费试玩游戏,而无需进行游戏下载,为用户体验更多游戏提供了便利,而 iOS 用户无法享受这一服务。

对此 Facebook 游戏官方账号还在 Twitter 上直接喊话 Apple 说道,用户能在安卓系统和 Facebook 的官网上使用云游戏,而因为苹果的政策,iOS 系统用户目前无法使用云游戏。

两家的不和源于 2018 年 3 月由苹果首席执行官库克发表的一条评论

2018 年 3 月,剑桥分析公司以不正当的方式获得了超过5000万用户的个人资料访问权,Facebook 在 2015 年已知剑桥分析公司这一行为,却没有发声,直到英国《观察家报》和《纽约时报》的报道发表后才通知公众这一事件,由此 Facebook 的隐私管理条例受到猛烈的抨击。

事件出来后,扎克伯格在 Facebook 上发表声明说:“我们有责任保护您的数据,如果不能,那么我们就不应该为您服务。”还提出了各种预防此类事件再次发生的措施。

面对此事,库克在一次采访中批评了 Facebook,称隐私权是美国的核心价值观,如果是他,一定不会让苹果遇到这种隐私泄露的情况。

此事又引出了两家之间的不和

苹果在上个月调整了有关游戏服务的准则,让应用程序可以提供多个游戏的订阅,但是每个游戏都需要得到苹果公司的批准并在自己的应用程序中提供。

面对此次的云游戏事件,苹果回应称,如果开发人员把每个游戏作为单独的应用程序提交到 App Store 中引入 iOS,或者通过 Safari 浏览器交付云游戏,这一服务便可以提供给消费者。

对于苹果的回应,Facebook 特殊游戏项目副总裁鲁宾直说,“苹果用‘政策上的失败’来回应我们 iOS 云概念的多个请求,比我们过去遇到的沉默更好,但这几乎不是‘有用的反馈’”,于是并未和苹果在此事上达成协议。

查看原文

赞 0 收藏 0 评论 0

袁钰涵 发布了文章 · 10月26日

好物分享 | 键盘清洁泥与护眼仪

先放一张格子衫图以示对格子衫的偏爱(格子衫真的有N种穿法,只要 get√ 得到,谁穿谁好看):

不说废话了,进入好物推荐环节:

好物一号——键盘清洁泥

小时候就喜欢晚这种软乎乎的东西,那时候家长总是害怕我会把泥吃进肚子里,长大后还是对这种东西情有独钟。

有空的时候拿起一团来,揉揉捏捏后一点点粘掉键盘上的脏东西,解压还治愈,感觉一周的烦恼都被黏走了。(这个蓝色也相当治愈呢)


好物二号——护眼仪

过去以为护眼仪挺贵的,一直没买,今年生日的时候朋友送了一部后,开始进入护眼仪圈子,发现这类产品其实性价比超高的,价格也没有想象中的贵。

护眼仪对经常需要疲劳用眼的人而言特别友好,市面上的很多护眼仪都有温度调节、按摩调节功能,选择合适的温度和力度,躺在那里听着护眼仪发出的白噪音,我经常一不小心就睡着了,最后还是靠家里人帮我把护眼仪拿下来。

那段失眠的日子里,是护眼仪陪我走了过来,算是我的宝藏好物了。

本文参与了 SegmentFault思否征文「1024 征文活动」,欢迎正在阅读的你也加入。

查看原文

赞 1 收藏 0 评论 0

袁钰涵 发布了文章 · 10月26日

苹果新机发售问题大汇总 | 影响部分卡片磁性、影响机械表运转、续航时间较短、直角边框划手

image.png

随着 iPhone 12/12 Pro 的正式发货和开售,关于使用苹果需要注意的一些事项也开始出现,这里对问题做了一个汇总,希望各位使用苹果新机时能有效避雷。

  • iPhone 12背部、MagSafe 充电器内嵌的磁铁,虽然不会让信用卡这种磁力强的卡被消磁,但面对房卡这类磁力较弱的卡片,可能会出现消磁隐患。官方是建议大家使用 MagSafe 的皮革卡包存放这类卡片,但小编这边的意见是使用普通卡包即可。
  • iPhone 12 的磁式无线充电与机械表保持一定距离情况下不会影响其时间准确性,但机械表碰到了手机背面、MagSafe 充电器或磁吸壳,部分机械表会出现明显的走时误差。使用时候需要注意机械表与手机的接触,最好是表与手机处于不同的两只手,这样磁力对机械表形成的影响是最小的。
  • 多款支持5G的手机屏幕最亮的状态下,浏览网页的测试结果显示,iPhone 12 和iPhone 12 Pro 续航时间分别为8小时25分钟和9小时6分钟,落后于三星 S20、一加 8T 和谷歌 Pixel 5。购买了苹果手机的朋友们对电池性能要做好心理准备,其续航时间有限,出门在外不方便充电时还是注意一下手机亮度和后台运行的耗电。
  • 对于苹果新机的直角边框,部分网友反馈会划伤虎口和大拇指,大家选择手机购买前,最好能到线下门店体验手感,确定自己的双手能承受这种设计再选择购买,避免造成不愉快的使用体验。
查看原文

赞 2 收藏 0 评论 0

袁钰涵 赞了文章 · 10月20日

思否独立开发者丨@向前兄:编程在一定程度上也是认识这个世界的一种方式

微信读书笔记导出插件“小悦记”.png

独立项目名称:微信读书笔记导出插件“小悦记”

思否社区ID:@我是菜鸟


@向前兄来自河南洛阳,最近几年在上海工作,目前(new Date())是前端开发一个。

微信读书笔记导出插件“小悦记”

2016年,在大学毕业不到一年后,他只身一人来到了上海,用着jQuery+Bootstrap做起了响应式官网,开启了坎坷的工作历程。后来又跳入了React Native的 “坑”,一个人摸索着把APP上了架。一时兴起,又做了一个前端单词的小程序。后来限于公司前端不受重视,又开始了新的探索。

眨眼间,忙忙碌碌又两年,也算是经历了一番。不知所得可值得?不知所失可拥有?

对他来说,编程在一定程度上也是认识这个世界的一种方式。

长路漫漫,踏歌而行。

众所周知,微信读书App 是一款非常优秀的阅读类App ,周围也有不少人在用。虽然工作比较忙。但是也没少在上面看书做笔记。

美中不足的是,目前微信读书虽然支持笔记导出,但是提供的是将笔记复制到剪切板,然后由用户自行粘贴到其他地方的功能。

如果你的笔记比较多的话,需要分好几次才可以批量人工导出,每次选择还得记住上一次在什么位置,非常不方便。粘贴出去的格式,也因软件的不同而千差万别。

如下图所示:选择的笔记内容超过了系统剪切板上线。请筛选后重试

微信读书笔记导出插件“小悦记”.png

@向前兄 时常感到非常不方便,于是,就顺手开发了“小悦记”这个可以导出多种模式的Chrome 插件。

他说自己目前并不是全职的独立开发者,主要是想解决下实际生活中遇到的问题(学而时习之,不亦说乎),锻炼一下自己各方面的能力,为以后做准备。

独立开发项目小悦记

立项时间:2020年1月10日前

项目背景:去年用微信读书看书的时候发现如果笔记过长的话,会有“选择的笔记内容超过了系统剪切板上线。请筛选后重试”的提示,多次复制粘贴在移动端很不方便。

本身也不太习惯用手机,后来发现微信读书网页版上线了,还可以直接查看读书笔记,于是就有了这个想法

做这个插件主要是解决手机系统的笔记剪切限制,另外就是看到微信笔记复制的内容在印象笔记的格式比较好看,然后想优化一下导出的笔记格式,纯文本的不是太好看。

面向群体:为了确保不是就我一个人遇到这个问题,做之前我在网上搜了下,确实也有人有类似的需求。

1、如何做的第一版产品?

刚开始起名字也比较费脑,毕竟logo之类的也要和插件名字或者读书笔记导出功能相关,太小众的话也比较难记,直接取名微信读书之类的又担心侵犯权利,就围绕着“阅读”,“笔记”这几个词在想,然后取名“小悦记”。

logo设计也是比较考验人的,本来打算是一本书的形象或者直接用 font awesome字体,然后发现没太合适的,而且和别的app重合度也比较高。

logo设计,付费的话,自己也承担不起,毕竟开发这个就是在用爱发电。

后来自己根据“悦”字联想,刚好左边的竖心旁可以当做笔,右边是兑换的兑,然后竖心旁的两个点“心”上面的两个点,我本来打算用手绘的方式,但是没有找到合适的工具,时间比较急。

虽然之前切图经常用Photoshop,但是基本上只会使用切图、像章工具,之前做的微信小程序“前端单词”的logo也是用PPT做的,这次的logo也不例外。

功能方面的话就自己试验,自己写自己测试。

2、独立开发过程中遇到过哪些困难?最难搞定的是什么?

好几年没有用jQuery了,刚开始都有点不会用了。

还有就是以往没有开发过Chrome浏览器插件,不是太了解里面的运行机制。去网上找的资料也都比较旧了,复制粘贴的一大堆,官方虽然有教程,但是似乎偏理论多些。

后来做出来之后,想转成火狐浏览器插件,但是没有通过,这个比较纳闷,我去网上找了个开源的插件库,对方的也没有成功转为Firefox 插件,后来我就没有再考虑Firefox浏览器了。时间不太够,基本上是周六周日空了看下代码。

比较难搞定的基本上是自己能力范围之外的东西,在这上面花费时间比较多,本来打算是在读书日前发布的,结果晚了好几天。

提交审核需要付费,还是找的朋友帮忙的。

刚开始的推广可能被官方注意到了?然后没过多久就有人反馈微信读书主页会有提示,并且插件不能用。我当时比较好奇他们是怎么检测出来的 ,搜出来的方法并不可取,后来我终于想出来 了,改完后发现社区有个人也提示了下,不过我没及时看到。

第二次提交审核不知道为什么没有通过(Chrome已经有266个用户),考虑到很多用户并非程序员,可能无法科学上网,就直接提交到360浏览器了。前段看到社区有人下载代码后在QQ浏览器上直接运行了。

微信读书笔记导出插件“小悦记”.png

3、项目目前取得了哪些成就?项目为你带来了什么?

成就倒没有什么成就,就是确实解决了大家遇到的一个问题,新发现不少,就当做探索了吧。

首先是公众号涨了不少关注者,认识了不少人。

其次是探索下推广方式带来的效果如何,意外发现还是比较多的,就当是试验了。

认识一个00后,发现大学生接触到的信息来源和我们那时候几乎完全不同(知道善用佳软和小众软件的估计都毕业好些年了)。如果有新的产品推广,可能要考虑受众群体和实际情况了。

中间有在知乎大V群发个红包,但是刚开始效果好像并不明显,后来陆陆续续有人点赞和收藏。

在阮一峰老师的科技周刊投稿,获得了一次曝光的机会。

最后感谢朋友圈各位朋友的转发和打赏。

4、你的商业模式是什么?是如何增长的?

目前没有商业模式,只是初步尝试,所以只放了个人网站和公众号的链接。

5、近阶段项目有哪些更新,未来会做什么变动?

暂时没有更新的打算,它已经初步完成了它 的历史使命。目前在考虑另外一个工具,也是来自实际遇到的问题,产品需求已经列了二十多条了,不过可能得到明年有空了才能开始。

6、如果项目重来一次你会做哪些改变?

首先可能会按照规定时间节点开发,其次是安排好推广渠道和方式,毕竟花时间做出来了,要把效果发挥到最大。一开始还设想了短视频的方式,不过精力有限,最后只是在公众号用图文的形式推广了下。

还有就是,投入更多精力,增加更多功能吧,其实在这之前也有有类似的产品的,不过切入点不一样。

个人相关问题

1、推荐你最喜欢的一款产品 / 游戏 / App?并说明原因

平常不玩游戏,也没有太高频使用的产品,手机还设置了限制时长。坐地铁经常看 Inoreader、还有几个读书APP。平常用电脑多,比较经常网上逛。

2、分享一下你的技术栈和你日常的工作流?

技术栈的话,工作中用到的是 JavaScript(ES6+)、React、React-Native、Mobx、SCSS、Taro、小程序等。业余时间学点Node和偏后端的东西。

image.png

3、对独立开发者或编程初学者有什么建议?

以前在网上看到一句话说,如果深入一个细分领域的话,还是有机会的,后来发现,中国人实在太多了,一个你觉得已经很细分的地方其实都有不少人在做了。

之前有在一个开发者群众看到说,国内用户可能目前还是习惯白嫖,付费意识不是太强。

做一个成功且优秀的产品需要很多的能力,编码只是其中一少部分。

前段不是有个新闻吗,82岁学编程的老奶奶。想学编程永远不晚,现在网络比较发达,各种资料都很丰富,也不用在意自己的职业是什么。

4、生活中有什么爱好?有什么个人的特别的工作习惯么?

爱好不算太多,空了看书、上网,闲了会打羽毛球,不过已经是好久以前的事了。

最近几个月刚把加班加肥的又通过跑步减肥10斤。

特别的工作习惯?好像也没什么特别的,相对来说比较注重效率,另外个人还是比较喜欢安静点的工作环境。

5、你对国内技术社区的看法

非常感谢思否社区,我在上面还提了好几个问题,都有热心的程序员帮忙回答。也在上面关注了不少厉害的程序员。我感觉国内技术社区还是有很大的想象力的,如果运营得好的话,毕竟程序员群体还是很大的。其他技术社区一般也会看,不过个人感觉帮助更大的可能是自己平常发现的一些个人博客之类的(可能层面不一样)。


开发者寄语

能在这里打个广告吗?国庆后打算找工作, 上海地区有招前端的吗?感兴趣的话求带走 (base64)bGN5eGxxbkAxNjMuY29t


独立开发者支持计划-1.png

该内容栏目为「SFIDSP - 思否独立开发者支持计划」。为助力独立开发者营造更好的行业环境, SegmentFault 思否社区作为服务于开发者的技术社区,正式推出「思否独立开发者支持计划」,我们希望借助社区的资源为独立开发者提供相应的个人品牌、独立项目的曝光推介。

有意向的独立开发者或者独立项目负责人,可通过邮箱提供相应的信息(个人简介、独立项目简介、联系方式等),以便提升交流的效率。

联系邮箱:pr@segmentfault.com

image

二维码过期添加思否小姐姐拉你入群
image.png
查看原文

赞 9 收藏 1 评论 0

袁钰涵 发布了文章 · 10月13日

“五眼联盟”添日本、印度两大成员国,多家科技公司对其十分抵制

image.png

美国当地时间10月11日,“五眼联盟”发表声明要求科技公司在加密应用程序中引入后门,以便政府可以合法获取加密软件中具有可读性和可用性的内容,与“五眼联盟”进行情报合作的国家中,加上了日本和印度两个国家的名字。两者的加盟增长了由美国、英国、澳大利亚、新西兰、加拿大组成的“五眼联盟”的力量。


“五眼联盟”成员国多年来窃取他国商业数据在本国的政府部门和公司企业之间共享,对此中国外交部发言人赵立坚曾在2020年6月29日发言强调,“五眼联盟”情报合作长期违反国际法和国际关系基本准则,对外国政府、企业和人员实施大规模、有组织、无差别的网络窃听、监听、监控,这早已是世人皆知的事实。

在2020年10月13日,我国外交部发言人赵立坚继续强调,长期以来,“五眼联盟”的成员国在没有任何证据的情况下,无端指责中国企业在产品中设置“后门”,威胁供应链安全和个人隐私。与此同时,“五眼联盟”此次毫无顾忌地公开要求企业在加密应用程序中设置“后门”,这不是典型的双重标准吗?


“五眼联盟”发表的声明中指责企业使用特殊加密技术阻止了政府对内容的合法访问,让政府的监管变得困难,并且呼吁各企业能在保护用户隐私的情况下,为执法部门提供信息,帮助其有效打击非法内容和非法活动。

但对于“五眼联盟”的发言与做法,全球多家科技公司都十分抵制,称为政府加入后门将会出现用户通信被泄露或是被犯罪分子拦截的风险,七国的这一做法将影响程序之间良好的加密通信,其行为与真正的数据安全原则背道而驰。

查看原文

赞 2 收藏 0 评论 0

袁钰涵 发布了文章 · 9月29日

Google 承诺对 Android 12 进行改进,给予程序开发者更多自由

image.png
9 月 28 日,Google 产品管理副总裁 Sameer Samat 发布博客称,听取开发人员反馈后对 Android API 和 Play 进行了更新。

反馈内容如下:

  • 支持开发人员选择不同平台(移动,PC和控制台)上的多个应用商店分发应用
  • 阐明关于谁需要使用Google Play计费系统以及谁不需要使用Google Play计费系统的政策;
  • 确保平台上所有应用程序(包括第一方和第三方应用程序)的平等待遇;
  • 允许开发人员直接与客户建立联系并进行交流;
  • 支持创新并采取提高用户使用体验的新技术。

在新版的 Android 12 中,开发者可以选择多个应用商店发布自身的应用程序,无论是第一方还是第三方应用程序都有平等的待遇,只要程序做得足够出色,即使是Google的竞争对手,精选中也会对应用进行推荐。


关于 Google Play 的收费,Sameer Samat 表示:所有在Play程序中销售数字商品的开发人员都必须使用 Google Play 的计费系统,当开发人员向客户收取下载其应用程序的费用或者出售应用程序内的数字商品时,按照一定的购买比例收取支付服务费。

需要进行收费的内容包括但不限于:

  • 商品(例如虚拟货币、额外生命、额外游戏时间、附加道具、角色和头像);
  • 订阅服务(例如健身、游戏、交友、教育、音乐、视频和其他内容订阅服务);
  • 应用功能或内容(例如应用的无广告版本或免费版本中未提供的新功能);以及
  • 云软件和服务(例如数据存储服务、企业办公软件和财务管理软件)。

今年因为特殊原因,许多企业需要通过一些应用程序把业务线上化,Google 对于这类程序的收费问题回应道:在接下来的12个月中,这类业务无需遵守 Google Play 中的付款政策,但在明年将会重新评估情况,制定其付款政策。


开发人员与客户沟通的问题,Google 集团产品经理 Mrinalini Loew 在博客中进行了回答称,开发人员可以通过发送电子邮箱或者其他方式,直接与客户进行沟通,可以对用户提供优惠政策、直接为用户退款,并且可以通过其他应用商场平台为客户提供不同版本的应用程序、功能和定价模型。


Android 12 更新后,只要应用程序不会破坏 Android 已采取的安全措施,其日后的使用、发布、出售都会更为自由,并且能根据开发者与用户的沟通自行调节,用户使用第三方应用程序也会更为方便。

查看原文

赞 7 收藏 1 评论 0

袁钰涵 赞了文章 · 9月29日

APP如何做到快速流量变现?我想我找到了答案

最近经常有开发者向我讲述他们在产品变现时候面临的一些痛点:

  • 我是开发者,想做流量变现,不知道如何接广告。随便找到了一个平台没想到点击率和单价这么低。
  • 接入某某广告平台的流程异常复杂,审核资料要求极多。形式很多样但却不知道哪种合适自己。
  • 传统想法以为如果要提高广告收入,你就不得不开始破坏用户体验,但这些都是导致应用走不长久的最下策。

其实这些问题是每个开发者都会遇到的,甚至不夸张的说很多开发者因为这些问题没有解决,不得不放弃一款产品。但这些问题真的很难解决吗?答案是只要找到正确的渠道,问题很好解决。

开发者们到底需要平台们提供什么帮助?

开发者们到底需要平台们提供什么帮助?

我认为是产品持续成长和更高的收益可能性。

其实从穿山甲平台的「新星助推计划」我们就可以窥见到平台帮助开发者解决问题的思路,并了解到开发者们能如何实现破局。

首先是从2020年9月持续至2020年12月底在50亿元优质开发者专项激励基础上,额外提供3000万元成长激励金,帮助500个开发者做到激励翻倍,每月将为成长中的高潜力开发者提供最高80%的额外收益补贴。

其次,平台推出Growth Lab,其中涵盖商业化、运营调优、数据监控分析等全生命周期多元化产品工具,从拓展广告场景、提升用户留存转化、提升产品ROI等多角度助力开发者科学复盘,帮助产品快速变现,突破产品成长瓶颈。

新星助推计划的种种帮助,转化到开发者方面,会给开发者变现和成长环境,带来三个维度的改善。

  • 首先,开发者相比以前更加的省心,开发者通过新星助推计划,能获得产品能力和技能培训全方位扶持,得到更加多元化和更全面的成长机会
  • 其次,参加的开发者能得到实在的金钱收益,入选的开发者可获得最高80%的额外分成奖励,也就是说,优质开发者月收益补贴额度最高将达到180%。
  • 最后,它让开发者更放心,不仅在APP体验上为开发者完成产品把脉,穿山甲更提供的全链路生态环境,开发者们可以更好克服数据孤岛,平滑向下一发展阶段过渡。从而实现变现与用户体验的平衡。

如果你也面临开发和变现中的困境,扫描进入下方小程序,报名「新星助推计划」

新星助推计划

开发者对「新星助推计划」的评价

关于「新星助推计划」,我也和几位资深开发者聊了一下,如果你想听听他们的看法,不妨往下看看。

社交产品开发者A:我个人觉得平台的服务力是非常重要的,参加了新星助推计划后,让我感受最深的是平台带给我的超贴心的服务,相对于其他竞品在这里我听到了最为专业的买量和变现指导。

工具产品开发者B:以前一直苦于没有多种开放的商业化能力和创新的广告场景,生硬的广告展现方式让我们流失了大量用户。接入穿山甲后,了解到了平台基于的多样的广告方式,特别是激励视频,为我们拓展了新的变现思路。这次使用后不仅让我们的产品得到了更大的收益,也有效增长了用户使用时长,提升了用户留存。

摄影APP开发者C:平时比较忙,没时间去学习产品变现知识,我在使用穿山甲的过程中,发现平台提供的「开发者成长中心」小程序里不仅有官方讲师全面解读开发者的变现难题,而且面向我们这些不同需求的开发者,还推出了不同难度的课程。使我能利用碎片时间学到一些很实用的知识。

移动端小游戏开发者D:为了测算ROI,我们不仅要全渠道埋点,还必须独自承担从埋点到统计分析变现、投放数据的人力成本。这样不仅分散了资源,无形之中还限制了团队的灵感发挥。穿山甲提供数据看板的能力,大大节约了我们的时间,从而不至于陷入繁杂的数据分析和体力劳动当中。

新星助推计划

虽然上面的内容已经让你对「新星助推计划」有了一定的了解,但亲身参与才会获得更多。对于成长中以及陷于变现难题的开发者们来说,新星助推计划的确是一个值得一试的活动。

扫描进入下方小程序,报名「新星助推计划」

新星助推计划

查看原文

赞 14 收藏 2 评论 0

袁钰涵 赞了文章 · 9月29日

浅谈Kotlin的Checked Exception机制

本文同步发表于我的微信公众号,扫一扫文章底部的二维码或在微信搜索 郭霖 即可关注,每个工作日都有文章更新。

现在使用Kotlin的Android开发者已经越来越多了。

这门语言从一开始的无人问津,到后来成为Android开发的一级语言,再到后来Google官宣的Kotlin First。Kotlin正在被越来越多的开发者接受和认可。

许多学习Kotlin的开发者之前都是学习过Java的,并且本身Kotlin就是一款基于JVM语言,因此不可避免地需要经常和Java进行比较。

Kotlin的诸多特性,在熟悉Java的开发者看来,有些人很喜欢,有些人不喜欢。但即使是不喜欢的那些人,一旦用熟了Kotlin进行程序开发之后,也难逃真香定律。

今天我想跟大家聊一聊的话题,是Kotlin在早期的时候争议比较大的一个特性:Checked Exception机制。

由于Kotlin取消了Checked Exception,这在很多Java开发者看来是完全不可接受的,可能也是许多Java支持者拒绝使用Kotlin的原因。但目前Kotlin已经被Google转正两年多了,开发了成千上万的Android应用。你会发现,即使没有Checked Exception,Kotlin编写出的程序也并没有出现比Java更多的问题,因此编程语言中对于Checked Exception的必要性可能并没有许多人想象中的那么高。

当然,本篇文章中我并不能给出一个结论来证明谁对谁错,更多的是跟大家谈一谈我自己的观点和个人心得,另外引用一些大佬的权威观点。

另外,这个问题永远是没有正确答案的,因为世界上没有最好的编程语言(PHP除外)。每个编程语言选择不同的处理方式都有着自己的一套理论和逻辑,所以与其去争论Java中的Checked Exception机制是不是多余的,不如去论证Kotlin中没有Checked Exception机制为什么是合理的。

那么,我们首先从什么是Checked Exception开始说起。

什么是Checked Exception?

Checked Exception,简称CE。它是编程语言为了保证程序能够更好的处理和捕获异常而引入的一种机制。

具体而言,就是当一个方法调用了另外一个可能会抛出异常的接口时,要么将这个异常进行捕获,要么将这个异常抛出,交给上一层进行捕获。

熟悉Java语言的朋友对这一机制一定不会陌生,因为我们几乎每天都在这个机制的影响下编写程序。

观察如下代码:

public void readFromFile(File file) {
    FileInputStream in = null;
    BufferedReader reader = null;
    StringBuilder content = new StringBuilder();
    try {
        in = new FileInputStream(file);
        reader = new BufferedReader(new InputStreamReader(in));
        String line = "";
        while ((line = reader.readLine()) != null) {
            content.append(line);
        }
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        if (reader != null) {
            try {
                reader.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}

这段代码每位Java程序员应该都非常熟悉,这是一段Java文件流操作的代码。

我们在进行文件流操作时有各种各样潜在的异常可能会发生,因此这些异常必须被捕获或者抛出,否则程序将无法编译通过,这就是Java的Checked Exception机制。

有了Checked Exception,就可以保证我们的程序不会存在一些隐藏很深的潜在异常,不然的话,这些异常会像定时炸弹一样,随时可能会引爆我们的程序。

由此看来,Checked Exception是一种非常有必要的机制。

为什么Kotlin中没有CE?

Kotlin中是没有Checked Exception机制的,这意味着我们使用Kotlin进行文件流操作时,即使不捕获或者抛出异常,也可以正常编译通过。

熟悉Java的开发者们是不是觉得这样严重没有安全感?

那么我们就来尝试分析和思考一下,为什么Kotlin中没有Checked Exception。

我在学习Kotlin时,发现这门语言在很多设计方面都参考了一些业内的最佳编程实践。

举个例子,《Effective Java》这本书中有提到过,如果一个类并非是专门为继承而设计的,那么我们就应该将它声明成final,使其不可被继承。

而在Kotlin当中,一个类默认就是不可被继承的,除非我们主动将它声明成open。

类似的例子还有很多很多。

因此,Kotlin取消Checked Exception也肯定不是随随便便拍脑瓜决定的,而是有很多的理论依据为其支持。

比如说,《Thinking in Java》的作者 Bruce Eckel就曾经公开表示,Java语言中的Checked Exception是一个错误的决定,Java应该移除它。C#之父Anders Hejlsberg也认同这个观点,因此C#中是没有Checked Exception的。

那么我们大多数Java开发者都认为非常有必要的Checked Exception机制到底存在什么问题呢?

这些大佬们例举了很多方面的原因,但是我个人认为最主要的原因其实就是一个:麻烦。

Checked Exception机制虽然提升了编程语言的安全性,但是有时却让我们在书写代码时相当抓狂。

由于Checked Exception机制的存在,对于一些可能发生潜在异常的代码,我们必须要对其进行处理才行。处理方式只有两种:要么使用try catch代码块将异常捕获住,要么使用throws关键字将异常抛出。

以刚才的文件流操作举例,我们使用了两次try catch代码块来进行潜在的异常捕获,但其实更多只是为了能让编译器满意:

public void readFromFile(File file) {
    BufferedReader reader = null;
    try {
        ...
    } catch (IOException e) {
        e.printStackTrace();
    } finally {
        if (reader != null) {
            try {
                reader.close();
            } catch (IOException e) {
                e.printStackTrace();
            }
        }
    }
}

这段代码在Java当中是最标准和规范的写法,然而你会发现,我们几乎没有人能在catch中写出什么有意义的逻辑处理,通常都只是打印一下异常信息,告知流发生异常了。那么流发生异常应该怎么办呢?没人知道应该怎么办,理论上流应该总是能正常工作的。

思考一下,是不是你在close文件流时所加的try catch都只是为了能够让编译通过而已?你有在close的异常捕获中进行过什么有意义的逻辑处理吗?

而Checked Exception机制的存在强制要求我们对这些未捕获的异常进行处理,即使我们明确不想对它进行处理都不可以。

这种机制的设计思路本身是好的,但是却也间接造就了很多填鸭式的代码,只是为了满足编译器去编程,导致编写了很多无意义的try catch语句,让项目代码看来得变得更加臃肿。

那么如果我们选择不对异常进行捕获,而是将异常向上抛出呢?事实证明,这可能也并不是什么特别好的主意。

绝大多数Java程序员应该都使用过反射的API,编写反射代码时有一点特别讨厌,就是它的API会抛出一大堆的异常:

Object reflect(Object object, String className, String methodName, Object[] parameters, Class<?>[] parameterTypes)
        throws SecurityException, IllegalArgumentException, 
        IllegalAccessException, InvocationTargetException, 
        NoSuchMethodException, ClassNotFoundException {
    Class<?> objectClass = Class.forName(className);
    Method method = objectClass.getMethod(methodName, parameterTypes);
    return method.invoke(object, parameters);
}

这里我只是编写了一段最简单的反射代码,竟然有6个异常要等着我去处理。其中每个异常代表什么意思我也没能完全搞明白,与其我自己去写一大堆的try catch代码,还不如直接将所有异常都抛出到上一层得了,这样代码看起来还能清爽一点。

你是这么想的,上一层的人也是这么想的,更过分的是,他可能还会在你抛出异常的基础之上,再增加一点其他的异常继续往上抛出。

根据我查阅到的资料,有些项目经过这样的层层累加之后,调用一个接口甚至需要捕获80多个异常。想必调用这个接口的人心里一定在骂娘吧。你觉得在这种情况下,他还能耐心地对每一种异常类型都细心进行处理吗?绝对不可能,大概率可能他只会catch一个顶层的Exception,把所有异常都囊括进去,从而彻底地让Checked Exception机制失去意义。又或者,他可能会在当前异常抛出链上再加一把火,为抛出100个异常做出贡献。。。

最终我们可以看出,Java的Checked Exception机制,本身的设计初衷确实是好的,而且是先进的,但是却对程序员有着较高的编码规范要求。每一层方法的设计者都应该能清楚地辨别哪些异常是应该自己内部捕获的,哪些异常是应该向上抛出的,从而让整个方法调用栈的异常链都在一个合理和可控的范围内。

然而比较遗憾的现实是,绝大多数的程序员其实都是做不到这一点的,滥用和惰性使用CE机制的情况广泛存在,完全达不到Java本身设计这个机制所预期的效果,这也是Kotlin取消Checked Exception的原因。

没有CE不会出现问题吗?

许多Java程序员会比较担心这一点,Kotlin取消了Checked Exception机制,这样不会导致我的程序变得很危险吗?每当我调用一个方法时,都完全不知道这个方法可能会抛出什么异常。

首先这个问题在开头已经给出了答案,经过两年多的实践发现,即使没有Checked Exception,Kotlin开发出的程序也并没有比Java开发的程序出现更多的异常。恰恰相反,Kotlin程序反倒是减少了很多异常,因为Kotlin增加了编译期处理空指针异常的功能(空指针在各类语言的崩溃率排行榜中都一直排在第一位)。

那么至于为什么取消Checked Exception并不会成为导致程序出现更多异常的原因,我想分成以下几个点讨论。

第一,Kotlin并没有阻止你去捕获潜在的异常,只是不强制要求你去捕获而已。

经验丰富的程序员在编写程序时,哪些地方最有可能发生异常其实大多是心中有数的。比如我正在编写网络请求代码,由于网络存在不稳定性,请求失败是极有可能发生的事情,所以即使没有Checked Exception,大多数程序员也都知道应该在这里加上一个try catch,防止因为网络请求失败导致程序崩溃。

另外,当你不确定调用一个方法会不会有潜在的异常抛出时,你永远可以通过打开这个方法,观察它的抛出声明来进行确定。不管你有没有这个类的源码都可以看到它的每个方法抛出了哪些异常:

public class FileInputStream extends InputStream {

    public FileInputStream(File file) throws FileNotFoundException {
        throw new RuntimeException("Stub!");
    }

    public int read(byte[] b, int off, int len) throws IOException {
        throw new RuntimeException("Stub!");
    }

    public void close() throws IOException {
        throw new RuntimeException("Stub!");
    }
    ...
}

然后当你觉得需要对这个异常进行捕获时,再对它进行捕获即可,相当于你仍然可以按照之前在Java中捕获异常的方式去编写Kotlin代码,只是没有了强制的要求,你可以自由选择要不要进行捕获和抛出。

第二,绝大多数的方法其实都是没有抛出异常的。

这是一个事实,不然你绝对不会爱上Checked Exception机制,而是会天天咒骂它。

试想一下,假如你编写的每一行代码,调用的每一个方法,都必须要对它try catch捕获一下才行,你是不是想摔键盘的心都有了?

我说的这种情况在Java中真的有一个非常典型的例子,就是Thread.sleep()方法。由于Thread.sleep()方法会抛出一个InterruptedException,所以每次我们调用这个方法时,都必须要用try catch捕获一下:

public class Main {
    
    public void test() {
        // do something before
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        // do something after
    }
    
}

这也是我极其不喜欢这个方法的原因,用起来就是一个字:烦。

事实上,可能绝大多数Java程序员甚至都不知道为什么要捕获这个异常,只知道编译器提醒我必须捕获。

之所以我们在调用Thread.sleep()方法时需要捕获InterruptedException,是因为如果在当前线程睡眠的过程中,我们在另外一个线程对中这个睡眠中的线程进行中断(调用thrad.interrupt()方法),那么sleep()方法会结束休眠,并抛出一个InterruptedException。这种操作是非常少见的,但是由于Checked Exception的存在,我们每个人都需要为这一个少见的操作买单:即每次调用Thread.sleep()方法时,都要写一段长长的try catch代码。

而到了Kotlin当中,你会不再讨厌使用Thread.sleep()方法,因为没有了Checked Exception,代码也变得清爽了:

class Main {

    fun test() {
        // do something before
        Thread.sleep(1000)
        // do something after
    }

}

第三,拥有Checked Exception的Java也并不是那么安全。

有些人认为,Java中拥有Checked Exception机制,调用的每个方法你都会感到放心,因为知道它会抛出什么异常。而没有Checked Exception的话,调用任何方法心里都感觉没底。

那么这种说法有道理吗?显然这不是真的。不然,你的Java程序应该永远都不会崩溃才对。

事实上,Java将所有的异常类型分成了两类:受检查异常和不受检查异常。只有受检查异常才会受到Checked Exception机制的约束,不受检查异常是不会强制要求你对异常进行捕获或抛出的。

比如说,像NullPointerException、ArrayIndexOutOfBoundsException、IllegalArgumentException这些都是不受检查的异常,所以你调用的方法中即使存在空指针、数组越界等异常风险,Checked Exception机制也并不会要求你进行捕获或抛出。

由此可见,即使Java拥有Checked Exception机制,也并不能向你保证你调用的每个方法都是安全的,而且我认为空指针和数组越界等异常要远比InterruptedException之类的异常更加常见,但Java并没有对此进行保护。

至于Java是如何划分哪些异常属于受检查异常,哪些属于不受检查异常,这个我也不太清楚。Java的设计团队一定有自己的一套理论依据,只不过这套理论依据看上去并没有被其他语言的设计者所认可。

因此,你大概可以理解成,Kotlin就是把异常类型进一步进行了简化,将所有异常都归为了不受检查异常,仅此而已。

结论

所以,最终的结论是什么呢?

很遗憾,没有结论。正如任何事物都有其多样性一样,关于Checked Exception这个问题上面,也没有一个统一的定论。

Java拥有Checked Exception机制并不是错误的,Kotlin中取消Checked Exception机制也不是错误的。我想这大概就是你阅读完本文之后能够得出的结论吧。

但是,希望你自此往后,在使用Kotlin编程程序时,不要再为有没有Checked Exception的问题所纠结了。

如果想要学习Kotlin和最新的Android知识,可以参考我的新书 《第一行代码 第3版》点击此处查看详情


关注我的技术公众号,每个工作日都有优质技术文章推送。

微信扫一扫下方二维码即可关注:

image

查看原文

赞 16 收藏 4 评论 2

认证与成就

  • 获得 20 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 9月14日
个人主页被 2.3k 人浏览