从入门到放弃,学习路上最大的心理障碍

今天下午读完了《计算》这本书的导论章节。在导论章节中,关于数学提出了几个尚未解决的问题,其中一个是数学的本体论,也就是说,数学到底是发明还是发现?这个问题直到今天(2024年),依然没有结论。

这个问题在我读高中的时候就有疑惑。说这个,倒不是想说明我自己年轻时候有过什么天才的往事。恰恰相反,正是因为心里有类似疑问,才会对数学这门学科的学习有诸多疑惑,最终导致我内心无法理解这门学科到底是做什么的?学来到底是解决什么问题的?她跟物理学,化学,生物学等等这些学科的关系是什么?特别是物理学,为什么物理学里有很多复杂的数学公式?为什么物理学的很多证明非要靠数学来解决?

从结果来看,数学确实是其他学科的基础,确实推进了其他学科的发展。但为什么会是这样呢?在我过往求学的十多年里,几乎没人能回答我上边的疑惑。这直接导致我对数学的学习仅仅停留在「够用」就可以了。然而今天下午终于释然了。正所谓念念不忘,必有回响。原来这貌似是个极难回答的问题,至今都没有结论。如果搞清楚了数学和物理世界的关系,会对这个世界乃至整个宇宙的了解都会进入一个新的阶段。

举上边这个小例子,是想引出我自己在学习一门新的学科时,特别是入门阶段的一个强迫症似的学习习惯。我自己在学习一门新学科或者新知识的时候,首先想要搞明白将要学的新学科或者新知识是关于什么的?学习之后我会收获什么?这门学科的边界在哪里?坦白说,如果在入门阶段我无法解决这些疑虑,大概率我会迈不过入门这道门槛,或者即便学到了一些技巧,但终归是不得要领,统统都是照猫画虎,想要达到灵活运用,几乎是不可能的。自然,脑袋里对这门学科也不会有一个系统的清晰的认知逻辑。这应该算是我自己在学习一门新学科或者新知识的时候的一个「心理障碍」。相反,如果我解决了这些疑虑,那么接下来的学习对我来说就会非常的「主动」。因为我知道了要学习的内容边界在哪里,我对我自己的学习程度就会有一个比较客观的心理预期,也就是说我对自己的学习进展可以做到心中有数,不自大,也不菲薄。

这个心理障碍其实在很多方面对我都有很大的影响,包括上学时期的学生阶段,以及毕业之后的工作阶段。

AI 时代的到来,我到底要不要转行?

在 2023 年 2 月 1 日,OpenAI 正式对外发布了 ChatGPT 的 3.5 版本,标志着通用 AI 技术正式「破圈」,不但引爆了计算机行业,也同时引起非计算机行业的广泛关注。对于身处计算机行业内的程序员们,也第一次深深的感受到了巨大焦虑。因为这一波 AI 技术在生成常见代码上有了肉眼可见的巨大进步。

2023 年 3 月,我自己正好经历了公司裁员,面临寻找下一份工作的困境。而与此到来的 AI,让我变得更加焦虑,期间甚至有过考虑转行的短暂尝试。所以,「AI 时代的到来,我到底要不要转行」这个问题也让我不得不有更多的思考。

经过过去一年多的发展和观察,虽然 AI 行业还在快速发展,但新闻舆论的声音似乎小了一些。同时也给了我自己一些时间来思考一下自己未来的职业道路。

那么,AI 时代的到来,我到底要不要转行?先说我自己的结论,短期内可以不用转行。这个短期是多短?我自己主观判断是至少「十年」。

为什么说是「十年」?我已经说过了,是主观判断……

那这「十年」的鸿沟是什么?现在 AI 不是已经可以生成代码了吗?甚至可以生成简单的软件项目。为什么不是两三年就完全取代程序员?因为这一波 AI 是以人类的自然语言作为输入,以生成式文字作为输出。然而人类的自然语言与编程语言之间最大的区别就是逻辑严谨性或者说是精确性。

程序员这个职业之所以存在,解决的核心问题就是将不精准的人类语言转换成精确的编程语言,以此来控制计算机。如果有一天 AI 可以将人类语言通过某种方式或者方案精准的转换成编程语言,那么程序员这个职业才会真正面临着彻底消失。

所以我上边说的「十年」只是给了一个相对长的时间范围。当然,也有人说三五年。我不是 AI 专家,所以在这一点上给不了精确的时间。但如果一个「专家」现在告诉你十年之内必定会「xxxxx」,其可信度也同样值得商榷。除非他能严谨的论证自己的结论。否则都可以看作是主观判断。

如果短期内程序员这个职业还能存活一段时间,那么 AI 的到来对这个职业会有哪些影响呢?

首先,就像网上很多媒体说的那样。AI 的到来一定会提升开发效率。这会不会导致从业人员锐减?以前需要十个人,现在只需要两三个人就可以搞定同样的开发任务。我认为短期内「会」,但长期不好说。为什么呢?因为市场一直在变化,如果市场能挖掘出新的需求,那么剩余的七个人依然可以继续从业。

其次,AI 的到来,肯定会进一步降低入门的门槛。但,同时也会拉升「专业」的门槛。现如今,即便是没有经过专业学习的人员,也可以通用 AI 生成一段代码片段来解决眼下特定的问题。这种情况下,可以被看作是一种入门门槛的降低。这意味着初级开发人员可以被部分非专业人员替代。相对而言,以前初级开发人员就需要提升技术水平才能入行,即所谓拉升了入行的门槛。所以,短期内开发人员供给会受到一定冲击。当然,现如今市场状况原本就不好,所以不能将当下的就业问题简单看作是 AI 的冲击。AI 只是未来一段时间的一方面原因,并不是全部。

最后,长期来看,其实是提高了成为专业程序员的门槛。至于市场到底还需不需要更多的开发人员,得具体看市场的发展需求。不过,关于这一点,我还是保持乐观的态度。私以为,万物互联的时代才刚刚开始,编程介质会越来越多样化。之前集中在 PC、手机 App。未来会有更多的可编程介质出现,至于需要多少开发人员我不知道,但是一定会是专业化更高的开发人员。

Kagi 搜索引擎

大概一个月前,将 Arc 浏览器换成了日常使用的默认浏览器,替换了过去用了将近十年的 Safari 浏览器。Chrome 浏览器也仅仅用作开发浏览器,日常使用是不会用的,原因也很简单,太占用内存,用起来感觉非常的「笨重」。

大概三周前,从 Arc 浏览器里的可选搜索引擎里了解到 Kagi 搜索。

说起来,在 Arc 浏览器里最先体验的搜索引擎是 Perplexity.ai。但因为日常使用代理访问网络,每隔一段时间不用再次访问就会触发 Cloudflare 的「人类」验证机制,很烦人。在寻找替换搜索引擎的时候,这才了解到 Kagi。

话说 Kagi 搜索引擎用了大概两天,我就决定将 Google 替换掉。最核心的原因就是因为没有广告。由于 Kagi 的搜索结果里没有广告,所以 Kagi 的收入基本来自付费订阅。我目前订阅了「乞丐版」,按照 Kagi 文档里的推荐,对于大多数使用者来说,基础版就已经够用了。将近三周用下来,也确实如官方文档里所述,远远用不完。当然,也可能是因为最近这段时间工作太忙,导致没有时间划水有关……

Kagi 除了没有广告之外,目前体验下来,搜索结果比 Google 也不差,特别是英文内容,我自己体验下来没有什么太大的差别。中文内容也几乎没有出现搜不到有用东西的情况,当然比百度要强太多了,单就没有广告这一条就甩百度几条街。

使用 Kagi 搜索,需要用户登陆,因为 Kagi 可以提供个性化搜索。比如我在这段时间使用过程中,将中文搜索结果中的百度内容权重降低了很多,所以即便是中文内容,百度的搜索内容也会出现的很少。当然,也可以将某个网站的搜索权重提高,这样对于一些有价值的小型网站会友好很多,同时也可以帮助你更准确找到相关内容。

Kagi 对于更高级的付费用户提供 Ai 搜索,目前对我来说还用不到,或者说,我还有其他可以用的 Ai 替代品,也许以后其他替代品到期之后也说不定会继续订阅 Kagi 的更高级服务。

总体使用下来,搜索页面上再也看不到广告了,也不会因为前脚搜索某个商品,下一秒「某宝」上就会给你推荐相关产品。

使用搜索引擎这么多年,第一次让我对搜索结果有一种清新的感觉,非常棒!

暂时关闭了播客的独立站点

关闭了今年一月份建立的独立播客站点。

原因是因为经过两个月的实际操作,实在没有时间来录制播客,即便后续如果有,也不会太频繁,算来倒不如暂时托管在 YouTube 上,以此节省成本。

理想总是很美好,但还是要面对客观现实,把精力集中放在最重要的事情上。不能再犯十年前的错误。

另外,还有一个小小的感悟。

十年前当初决定技术方向转型的时候虽然年纪也不小了,按照行业的「规矩」,过不了三五年就会面临「大龄」问题而被淘汰。

记得当年独立开发者失败之后,兜里已经没钱了。在两年多没进公司工作的情况下,加上 Web 开发几乎零经验,能成功转型也是堪称一个奇迹。真是「自信」即巅峰,自助者天助。

Arc 浏览器使用体验

过去一周时间,尝试了 Arc 浏览器。体验可以说是非常的好,甚至将其设置成了默认浏览器。同时也将 iOS 上的默认浏览器也切换成了 Arc。可惜没有 iPad 版,iPad 上的版本是 iOS 的兼容版。

喜欢的点

  • 淡化 URL

Arc 访问 Web,更像是访问本地应用,如果网络足够快,Web 应用体验很好,使用过程中要比现有的浏览器有更好的沉浸感。甚至在使用的某一个瞬间几乎忘记是在使用Web 应用。

  • 多 Space

所谓的 Space,就是使用场景。使用场景之间的切换真是方便太多了,只需要手指左右滑动,即可完成场景的切换。工作和个人的 Space 切换,让不同内容互不干扰。

  • 将默认搜索引擎从 Google 切换成了 Perplexity

目前还不敢确认能否最终替换 Google。因为经过过去一周的使用,除了每天在第一次使用的时候会触发 Cloudflare 的安全检测以外,又发现一个新的问题,就是对给出的结果还是不太多元化。

怎么说呢?在大多数时候,Perplexity 给出的前六个搜索结果都还行。但如果想探求更多的不同信息,想要进一步交叉验证,就变得有些困难。不过,对于大多数使用场景,其实体验已经很好了,这一点还是有一说一。

  • 方便的 Split 双开

Arc 可以很方便的左右双开,加上自带的笔记功能,可以左边打开在线资料,右边打开笔记,一边看资料,一边做笔记,非常的方便和自然。

体验了一次左边开YouTube 视频讲解,右边做笔记,非常丝滑。

  • iOS 版本不是 macOS 版本的延续

iOS 版本跟 macOS 版本没有什么太大的关联,基本上交互是自成体系。iOS 版本的使用体验目前也还挺好的,自有其特色。关键还是脑袋里不要总是想着 macOS 版本与 iOS 版本有什么关联就还好。

  • 实用的小工具

macOS 版本有很多很实用的小工具。比如快速的截屏工具,可以自定义网页的 Boost 工具,以及提供可以在线分享文档,也就是上边提到的笔记可以通过在线链接的方式分享给第三方。

  • AI 加持

现在 AI 已经深入到各个产品,Arc 也不例外,提供了很多 AI 加持的工具,比如 iOS 版本对网页的归纳总结功能。macOS 版本通过 ChatGPT 直接回答问题等。

不完美的点

  • 没办法将 macOS 版本的密码同步到 iOS 版

目前来看,这个功能还在探索中,想必还没有考虑清楚。原因么,大概也是因为 iOS 版本的交互跟 macOS 版本差异太大,统一的技术方案还在探索中吧。另外,Windows 版本还在研发阶段,开发资源或许比较紧张吧。

  • 基于 Chromium 的 macOS 版本还不够完美

目前 macOS 版本一旦涉及到 Chromium 的个别设定,还是会有一些瑕疵或者说小 bug,但是不至于影响使用。只不过让强迫症会有些难受。

  • macOS 版本的密码没办法导出

macOS 的密码除了不能与 iOS 版本同步以外,还不能独立导出。如果将 Safari 或者 Chrome 的密码导入,那么此时就无法将密码导出。所以这也是目前让我将密码导入变的很犹豫的点。

总结

Arc 是真的好用,完全打破了之前使用浏览器的使用体验。如果 Arc 能够流行起来,我大概率会从开发 App 产品重新优先考虑 Web 产品,原因就是因为在 Arc 上使用 Web 产品真的很像使用 App。

被上传了将近两百个 G

今天早上醒来发现国外的很多网站上不去了,虎躯一震,立马看了一下代理,竟然是流量用完了。

代理的流量计算是上行和下行的总和。登录后台,看了一下过往一个月的流量统计,发现上行流量占了将近两百个 G。上行流量突然增加的时间是从 2 月 23 日,也就是大年初三开始。那些天没有用过电脑,在家一直用手机上网,一时想不出来为什么流量猛增,而且还是上行流量。

紧接着又查了一下过往 24 小时的流量,发现 Proton Drive 仅在过去 12 小时上行流量就用了 7 个 G。虽然 2 月份的流量数据统计在 macOS 上已经不太好查到,但就过去 24 小时的流量使用情况来看,基本可以初步确定是 Proton Drive 干的。还有另外一个重要的原因,Proton Drive 上一共存储的数据也就 5 个多 G。单就这一晚上上传 7 个 G 流量来看,就完全不正常。

短暂考虑之后,决定将 iOS 和 macOS 上的 Proton Drive 立刻删除,并且以后会非常警惕第三方云端硬盘的 App。现在手机上只保留了一个 Dropbox,里边只会对 Ulysses 的文章做可选项的备份服务,其他数据全为空,并且日常处于关闭状态,需要的时候手动开启同步,用完立即关闭。以后自己搭建 NAS 之后再考虑开启日常备份。

一年一度的个人所得税申报踩坑

今年的个人所得税申报踩坑了,记录一下。

2019 年 1 月 1 日开始,实行个人所得税申报,一年一次。申报方式基本上都是通过一个叫「个人所得税」的手机 App。

老实说,我自己对财务真的是一窍不通,主要也是对这个不太感兴趣,所以往年的很多次申报都是我老婆帮我填写,我自己只填写过一次?好像只有第一次是我自己填的,总之印象里已经完全记不清了,只记得进入 App 之后一直点击「下一步」,然后就会有一个退税或追缴的结果。

今年因为工作原因,只能自己缴纳。

前几天在「个人所得税」App 上进行了预约。我竟然连每年申报之前都需要预约这事都忘的一干二净了,事后问了我老婆才隐约想起来,往年其实也是需要预约的。

今天是预约申报的日子。好在提前几天在「提醒事项」App 上添加了弹窗提醒,否则也是忘得一干二净了。

进入「个人所得税」App 首页,直接进行申报,麻溜点击「下一步」,不到一分钟,申请完毕,需要补交 x 元税费,金额比往年都多,我还纳闷为啥去年需要补交这么多?但我还是通过支付宝把钱给老实补缴了。把这事跟我老婆说了,她提醒我是不是没有填写「专项附加扣除」?我才隐约意识到,往年好像确实是先填写「专项附加扣除」,然后再申报。

随后在「个人所得税」App 上先重新填写「专项附加扣除」项,然后在已经申报的流程里找到了「重置申报」的按钮,重新填写。一路下一步,结果果然不仅不用补缴,还会退 x 元税费。

走完重置申报流程,申报的状态变成了「申请退税」,点击「申请退税」,弹窗提示「税款未入库,暂时无法申请退税,请稍后重试」。网上查了一下原因,是因为税款只是已扣除,还未进入国库,所以退税的流程需要等钱先进入国库,然后才能继续走下边的退税流程。网上查的信息是需要等待三到四个工作日。

想来如果有人跟我一样,不知道怎么报税,每年就会多交很多钱。如果一直没人提醒的话,就会一年又一年的补缴。这个「坑」挖的好哇,国库的税收只赚不赔。

其实,我想说的是,父母家人这种信息,其实 App 完全可以代劳,甚至独生子女也可以 App 代劳。这些信息在街道办早就已经有了。另外在填写申报之前,完全可以提醒用户是否有需要填写的「专项附加扣除」,甚至可以放在申报流程之前让用户优先确认,再不济也应该在填报流程开始前很醒目的告知用户,而不是悄无声息的直接就让用户申报。

SwiftUI 中的 @State 与 @Binding 和 @ObservableObject 与 @ObservedObject 以及全局 @EnvironmentObject 的极简示例

SwiftUI 提供了一套强大的属性包装器,帮助管理状态和数据流。以下是这几种属性包装器的定义和用法。

  1. @State 和 @Binding:

• @State

@State 是一个属性包装器,用于在 SwiftUI 视图中声明本地状态。当 @State 变量的值改变时,它将使视图失效,并促使视图重新渲染。它通常用于简单的本地组件状态,这些状态不需要共享给其他视图。

例如:

import SwiftUI

struct Content: View {
    @State private var isToggled = false

    var body: some View {
        Toggle("Switch", isOn: $isToggled)
    }
}

• @Binding

@Binding 是一个属性包装器,它提供了对一个 @State 属性的引用,或者其它 @Binding 属性的双向绑定。它允许不同的视图共享对同一状态的访问,并能相互更新状态。

例如,使用 @Binding 将状态传递到子视图:

import SwiftUI

struct Content: View {
    @State private var isToggled = false

    var body: some View {
        ChildView(isToggled: $isToggled)
    }
}

struct ChildView: View {
    @Binding var isToggled: Bool

    var body: some View {
        Toggle("Switch", isOn: $isToggled)
    }
}
  1. @ObservableObject 和 @ObservedObject:

• @ObservableObject

这是一个协议,当遵从该协议的类的某些属性被标记为 @Published 时,这些属性在发生变化会通知其订阅者。通常用于定义外部的数据模型或状态,这些模型或状态将被多个视图访问和修改。

import Combine
import SwiftUI

class MyModel: ObservableObject {
    @Published var isToggled = false
}

struct Content: View {
    @ObservedObject var model = MyModel()

    var body: some View {
        Toggle("Switch", isOn: $model.isToggled)
    }
}

• @ObservedObject

这个属性包装器用于声明一个视图要观察的 ObservableObject 实例。当这个实例的 @Published 属性发生变化时,它会重新渲染视图。

  1. @EnvironmentObject:

@EnvironmentObject 是一个属性包装器,用于从环境中获取一个由某个父视图提供的 ObservableObject 实例。这对于跨多个视图共享数据模型非常有用,不必显式地将模型一层一层传递下去。

例如,在根视图中提供环境对象,并在子视图中访问它:

import Combine
import SwiftUI

class SharedModel: ObservableObject {
    @Published var isToggled = false
}

struct Content: View {
    @StateObject var model = SharedModel()

    var body: some View {
        ChildView()
            .environmentObject(model)
    }
}

struct ChildView: View {
    @EnvironmentObject var model: SharedModel

    var body: some View {
        Toggle("Switch", isOn: $model.isToggled)
    }
}

使用 @EnvironmentObject 之前,需要确保在视图层级中的某个点已经往环境中注入了对象,通常是在视图树的顶层进行。如果在环境中找不到相应的对象,那么试图访问 @EnvironmentObject 会导致运行时错误。

如何将 Xcode 中 Vim 模式下的 JK 按键映射到 ESC 按键

自从 Xcode 推出 Vim 模式,我就研究了一下如何在 Xcode 中开启。

有趣的是我在日常使用中并不会将 Xcode 作为常用编辑器。甚至可以更绝对一些,日常工作学习中几乎就不会使用 Xcode。一来是因为 Xcode 太「重」,启动很慢。二来也不开发 iOS App。开启 Vim 模式的原因仅仅是因为好奇,加上日常自己写代码使用 Vim 较多,所以就想感受一下在 Xcode 中使用 Vim 是怎样一种体验。

对于 Vim 的使用,虽然会有很多快捷键,但使用最频繁的就是 ESC 按键。我在自己的 Vim 设置中,就是将 ESC 按键映射到了 JK 两个按键,也就是连续快速点击「J」和「K」就会触发 ESC 按键。

但 Xcode 并没有提供 Vim 模式下的自定义按键的映射功能。最近重新学习 iOS 开发,对于 ESC 按键的映射实在忍无可忍。终于让我找到了一种「曲线救国」的方案。

实现这个功能的是一款 macOS 系统下的开源键盘映射软件,名字叫「Karabiner-Elements」。

首先,直接到官网下载最新的版本。

接着,按照官方文档的截图示意进行授权安装。安装过程包括开启对应的系统权限,相应的根据提示开启即可。官方文档的步骤很详细,还配了截图,步骤不算多,很快就能设置完。

安装完成之后,本地启动「Karabiner-Elements」App,点击窗口左侧的「Complex Modifications」,如下图所示:

点击右侧设置界面顶部的「Add your own rule」按钮,将弹窗里的默认配置删除。打开 Gist 页面,复制里边的 json 配置信息,将其原封不动的粘贴到弹窗里,点击弹窗右上方的「Save」按钮,保存配置。完成之后即可看到一条名为「jk to escape for xcode」的配置。

此时,在Xcode 中开启 Vim 模式(如果已经是开启状态,可以直接体验),即可享有 「J」「K」 按键映射到 ESC 按键的丝滑体验。

Gist 中的配置是我根据网上找到的一份配置稍微进行了的修改,如果想自行修改配置,可参考官方配置手册

如何在 Xcode 点击 command+S 保存时,自动对 Swift 代码进行格式化

开始学习 SwiftUI,发现 Xcode 貌似没有自动格式化的功能。网上找了一些资料,有些教程里的截图已经过时了,简单摸索后,重新总结了一下。

完成此功能,一共需要三步:

  1. 安装 SwiftFormat-for-xcode 插件
brew install --cask swiftformat-for-xcode
  1. 系统设置

插件安装完成后,需要先进行系统设置,路径如下:

系统设置 -> 隐私与安全性 -> 扩展 ->Xcode Source Editor

点击 Xcode Source Editor,出现一个弹窗,将 SwiftFormat勾选上。

此时,重启 Xcode,完成后会在 Xcode 的 Editor 选项下方出现 SwiftFormat 选项,说明 SwiftFormat 已经安装完成。

但如果想在 Xcode 点击 command + s 保存的时候执行格式化,还需要最后一步设置。

  1. keyboard 快捷键设置

按照如下路径,从系统设置进入:路径如下:

系统设置 -> 键盘 -> 键盘快捷键(键盘导航下方) -> App 快捷键

点击窗口右侧的 + 按钮,如下图所示添加快捷键:

其中 「Format File」可以根据你喜好编辑为「Format Selection」或「Lint File」,点击「完成」即全部设置完毕。

此时,在 Xcode 中编辑代码后,点击 command + S 保存时,会自动执行 Xcode 中 SwiftFormat 功能。