女朋友吐槽我说,我似乎不像曾经那样,愿意花钱了,开始有点变的小气。
我也在想,为什么会变成这个样子?
想了想,可能是因为目标感不同。
当年刚毕业 / 还在学校的时候,我对于结婚这件事没有那么高的预期,并不预期我马上会要结婚,所以存钱不重要。不需要储蓄,重要的是及时行乐。
如今的我,需要考虑结婚、彩礼、买车、买房、长期发展,担子一重一重都在眼前,自然会显得更加小气、抠搜。
目标感的不同,让我选择了不同的方式和方法。
过去的我不在乎未来,只在乎当下。如今的我,在乎当下,但更在乎一个美好的未来。
可是,没有当下,又谈何未来呢?
最近在看一个前端项目,里面出现了一些令人血压暴涨的骚操作。虽然可以用,但对我来说,确实是让我看到血压飙升。
1. 尽可能使用常规的指标
项目的诉求是实现页面的自适应化,在不同尺寸的屏幕上尽可能保持一致的显示。
为了实现这个诉求,我给他们的建议是使用 Bootstrap 之类的框架,在不同的屏幕上尽可能保持一致。使用 Bootstrap 之类的框架来完成。
最后研发团队选择采用了一个有用,但我看起来非常头疼的方法 —— 根据屏幕宽度计算 rem。通过这样的方式,实现了在不同的屏幕宽度下,都可以和设计稿的尺寸一比一。
但这样带来的问题是,rem 计算出的结果也是一个非常的大的值(当然也可以非常小),但依然不是一个常规的结果,需要你常常使用诸如 0.03
这样的数值来指定宽度和高度。
我觉得,这样的写法并不是说不行,只是这样的写法其实会降低整个项目的可维护性。
2. 文件放置符合规范
其次,这个项目中还出现了一个问题是 —— 文件到处乱丢。在一些项目中,大家往往会有一些明确的文件路径的规范,比如样式文件应该放在哪里。在这个项目中,就出现了样式乱丢的情况。
和 Component 放在一起
符合规范统一放在 scss 文件中
这样的混乱的写法则会导致在实际开发的时候,如果想要调整样式,可能会出现调试失效,修改起来较为混乱的问题。
3. 一个项目中混用多个不同的尺寸单位
另外一个文件采用 px 作为单位
刚刚有用 rem 的单位,另外就有一个文件采用的是 px 为单位,我非常担心在不同尺寸屏幕下出现的错位问题。
4. 放弃 Bootstrap 的样式类,转而改用手动撰写每一行样式
其实完全可以用 position-absolute d-flex 等方法来覆盖
总结
这个项目从我目前的视角来看,依然还有很大的改进空间。且留下了不少的坑。在我看来,长期来看,这些代码将会留下不可维护的问题。希望他们后续慢慢修改和调整吧。唉。
我们在生活中遇到一些让人不舒服的事情事,会有两种路线:
- 认识到这是个问题,并努力的去改变他,让他变得不再是个问题
- 认识到这是个问题,但告诉自己,总会习惯的
如果你发现自己在最近遇到一些事情时总是后者,就需要警惕「习惯」了。
我们需要警惕“习惯”,因为习惯的力量太过于强大,他可以把一切不合理的东西合理化。而一旦不合理的事情合理化,就会让我失去把事情变得更好的可能。
警惕「习惯」,努力让这个世界变得越来越好。
对于我来说,如果我不需要为了生存而进行产出,那我可能会希望自己能够保持静默,持续的去学习一些东西,学习一些「无用之学」。
背后的原因很简单,我拥有好奇心,我的好奇心驱使我去做更多的事情,而学习,正是满足我自己好奇心当中重要的一部分。
受限于生存压力,当下的我很难做到能够随心所欲的去学习一些东西 —— 你要追求财富、你要追求成功、你要追求事业有成。但这些东西可能只是表象,可能只是社会所赋予我们的压力。
回归到最后,还是要看你像做什么?
就我自己而言,我会学很多东西、体验很多东西,还有一个不会变的,可能就是通过 Coding 来改变世界,毕竟,这世界上有太多需要被改变的东西了。
先上链接: https://t.me/+azWuudfqVsM5MDQ1
这个 Channel 是一个我用来阅读的时候,随手发一些信息到里面的 Channel。他会包含了我觉得「有意思的别人的话」,如果你对于我在看什么感兴趣,那么这个 Channel 会是你需要的。
作为一个表达欲很强的人来说,我其实有着非常强的诉求有个渠道去发一些东西,但现有的很多平台发这些零碎的东西会让别人感受到不好,所以我能做的便是创建一个隐私的 Channle 来发布,这样就不用担心对别人的影响了。
少楠曾邀请我在小报童上开一个专栏来分享,不过我一直觉得,我自己能分享的信息过于碎片,担心难以让读者们满意,所以决定还是放弃开专栏的机会,更多是向内求, 不去做更公开的分享,而是做一些更加小众、更加舒适的分享。这个 Channel 就是我的一个尝试。
一直以来,大家都以进入互联网企业为荣,绝大多数人都在想这个问题。
但,价值是否真的在互联网?
一直以来,互联网企业都因为工资高等特点被广大开发者所关注,但随着互联网的增量减少,很显然,互联网的高工资难以维持。互联网对于工程师的诉求也会逐渐的减少。
在这个时候,每一个软件工程师都需要思考的一个问题是 —— 如何在这样的大背景下生存?
一个是找到有增量的互联网市场 —— 比如出海,到第三世界国家去进行产品开发(不一定人要去,但至少业务要去)。在这个市场,竞争不那么激烈,你依然可以维持高增长,获得更高的收益。
另一个是可以思考 IT 企业的本真价值是什么?互联网企业也好、软件企业也好,本质上是通过提升效率,让过去不好做的事情现在变得更加简单(微信提升了沟通的效率、淘宝提高了交易的效率、微博/Twitter 提升了发布观点的效率)。因此而产生价值。
而被互联网化/数字化的行业和领域并没有我们想象的那么多,大量的行业都还在使用一些非常传统和古朴的手段来进行信息的处理和交互,这些行业值得软件企业/互联网企业深耕,推进更多的企业数字化,并跟随这些企业的数字化来产生价值。
不过,也需要注意的是,无论是方案一,还是方案二,都已经不是「捡钱」的难度了,都需要你深耕行业,并在深耕的基础之上,创造价值,才能收获相应的反馈。
作为一个创作者,我对于自己的要求不算高,但也不算低 —— 我希望我能持续有输出。
但我也深知,我是一个普通人,我无法让自己永远有的写,永远有的说。为了解决这个问题,我给自己提供的解决办法是 —— 让自己沉浸在足够的信息当中。
我的逻辑是 —— 我写的文章大多并不是完全创新的(技术的除外),这些文章的灵感来自于我每天的所思所想,而所思所想来自于我的摄入。如果希望有足够的输出,足够的摄入是不可或缺的。
基于上述的逻辑,我得出了我应该做的事情 —— 尽可能多的订阅播客/Blog/微信公众号,收集到尽可能多的信息,然后从这些信息中筛选出我自己所需要的,并与其产生互动(比如诞生一个新的灵感)。
从某种意义上来说,我能够有这么多的文章灵感、软件的灵感,都来自于我的这些海量的输入。
当然,这些海量的输入也为我带来一些不爽的点 —— 比如,信息量太大了,我往往是无法看完所有的信息(当然,我也不太强求自己能看完所有的信息),也在追寻更好的信息摄入的方法,希望自己可以更加轻松的处理这些信息。
昨天和一个朋友聊,这个朋友在现有的公司做的不开心,觉得现有的公司已经脱离了他早期加入公司时的样子,想要离开现在的公司,寻求 Web3 公司的机会。
对我来说,我给到的建议自然是肯定的。
这个朋友在开源社区呆了很久,也有了自己的影响力和人脉,在我看来,他已经脱离了求生存的阶段,已经不会因为离开当前的公司就完全无法生存,他完全可以找到一份适合自己的工作。既然如此,为什么不选择一个能够让自己开心的同时,还能赚到钱的工作?
对于 90 后这一代人而言,我们当中的有些人还在奋斗的途中,但也确实有他这样的,其实家境还可以(不需要他奋斗脱贫),上一代人打下来良好的基础,让我们可以选择去做自己喜欢的事情,就没必要完全浪费自己的生命和时间在一些自己不喜欢的事情上。
勇敢的走出现在,去做你想做的事情吧。
前两天看到 V2ex 的一个帖子,提到了关于奋斗,正好也聊聊我自己关于奋斗的看法。
我其实一直都明白,我不是很聪明,我只有中人之姿(普通人的资质),因此,我不奢望能够与同龄人当中的优秀者比,因为我知道,我真的比不过,别人用一小时可以做完我需要用五个小时才能做完的事情。
但,天资不够不意味着不需要努力,对于我们每一个人来说,我们的奋斗,是为了让自己从当前的起点,进入到一个新的高度,而不是和天才做比较。哪怕我们奋斗到的新的高度,也不过是别的人起点,但至少相比于曾经的自己,我们达到了一个更高的高度,获得了更好的生活。
如图所示
我最近在写一些 Agora 的 RTC/ RTM 应用的教程,在开发 Demo 过程中,发现调试 Agora 的应用比较复杂,其实可以有一些辅助工具来帮助开发者更好的开发这些应用。
核心诉求
可以更加简单的调试 Agora SDK 当中的 Event
形态
- 独立的 Vue Componet / React Component
- 基于浏览器的 DevTools
基本功能
- 支持触发事件(应该是一列 按钮,用户点击后,就会触发对应的事件)
- 支持发送信息(应该是一个文本框 + 一个提交按钮)
- 支持查看频道内已有信息(最好还可以有筛选,这样方便只看自己关注的信息)
- 支持查看 Client、Track等基本信息(如当前人数、当前用户列表等等)
为什么一定是独立的 Client?
在实际开发时,业务的逻辑和实际使用到的功能可能是需要多个步骤才能触达的。此外,根据应用的特性,还可能会有浏览器锁定、设备锁定等业务能力。这些能力虽然与 Agora 无关,但会影响调试时的难度,因此,有一个单独的 Client 可以用来调试 Agora 是一个不错的选择。
为什么最好是 Component / Devtools ?
在实际的开发过程中,我们可能会用到 Agora 的 Token 机制,借助这个机制,我们可以对我们的音频/视频 Channel 设定准入门槛,降低成本。但相应的,调试起来比较麻烦。
如果是 Component / Devtools ,可以通过传入 Props / 环境变量来完成 AppID 和 Token 的设定,降低调试的成本。