Ep 44. 与 Tualatrix 聊聊独立开发使用的技术栈
57:31 Share

各位听众大家好欢迎来到最新一期的补书者说我是主播 Like9M 然后这期我们非常高兴的请到了图拉顶来和我们聊一下独立开发以及他在独立开发中用到的一些技术战相关的话题然后让我们欢迎图拉顶

大家好不说就说的各位听众我是图拉顶我很高兴今天能在这里跟大家分享我过去的一些经历还有当下的一些情况对 然后图拉顶也真的是我们想请的请了非常久的一位嘉宾然后我们今天另外两位主播是星涛和 Adam 也来跟大家打个招呼吧嗨 大家好 我是星涛大家好 我是 Adam 好 对我觉得可能

虽然我们都知道图拉顶在中文圈尤其是中文技术圈是非常有名的可能不是所有的听众都对你非常熟悉你要不要先简单做一个自我介绍

我也迭代一下我的自我介绍好了我曾经长期称自己为独立开发者但是我最近就是觉得自己是一人软件公司就是我想把自己从一个开发者往更专业的公司的方向去运营然后作为开发者我长期就是

Apple 软件生态的开发者但其实我在做 Apple 生态的开发之前我也是在 Linux 和开源社区做过一些产品的

我的技术站会比较偏在后端方面会比较偏向 Python 然后在客户端方面自然用的是苹果的原生技术比如 Swift AppKit UIKit 这一类差不多就这些吧后面我会在分享中更多的介绍好的好的对是然后就其实图大鼎有一点重要没介绍就是你做了哪些产品因为其实做了

今天你还做相当多东西对吧对也可以简单介绍一下

我按时间轴顺序来吧,说起来都是暴露年龄大概 2007 年,就 15 年前我在大学的时候当时是边学 Linux 边做了一款桌面设置软件是 Ubuntu Tweak 然后大概到 2013 年的时候我是做了一款商业的 Mac 上的软件叫 Manico

然后 2015 年的时候我又做了一款 iOS 上的 APP 极点是微博客户端但现在已经下架了

然后后面大概每隔几年就会做一款应用但那些产品基本上都是工作了一段时间然后出来 break 的时候做的或者是在大学的时候做的然后过去四年相当于自己就是比较笃定要走这条路了所以过去四年的产品比较多其实也没那么多就过去四年无论是自己独立开发完成的还是说跟朋友一起合作开发的

大概有比如 2019 年有做过 WinSwitch 一款 Mac 上的设置工具这是我跟朋友一起合作的然后当同年我还跟另外一个朋友合作了做了一款 iOS 上的效率工具集叫效率控嗯然后后来 2021 年的时候我自己又独立开发了一款剪贴版工具 MacOS 上的叫 Paste Now 嗯

然后过去一年我在做新的一款产品是 Reader Later 方向的但可能也不仅仅是 Reader Later 现在仍在开发中还没有发布已经跳票了好几个月了呃这款产品叫 Mark Mark 我预计今年发布是有点悬但目前已经在 Public Beta 了所以我只要继续不断的去做肯定是会发布出来了大概是这样一个时间轴吧啊

可能中间会有些小作品什么没有提到但没关系就是主线差不多就这样也是有非常多的作品也很期待你的 mark mark

能够尽快发布对其实我在那个临近录音之前加了个新的话题我就挺有意思就是我不知道信涛和 Adam 你们有没有用图拉顶在开发的产品如果有用也可以聊一下因为我自己是用了 Manico 也挺多年了然后我觉得很方便对

并且我在录音前,可能开始的半个小时前去下了一下 OneSwitch 因为我原来不知道你有做这个产品我觉得也...有一些需求你知道用户是不知道他自己需要是的要亲自去玩过才会发现自己有没有这个需求不知道信涛和 Adam 你们有用或者用过吗我有用过

我有用过几个一个是 Ubuntu Tweak 但是现在我已经不用 Ubuntu 了但是当时真的是就是你想作为一个小白用户你一边在看鸟哥的 Linux 四王菜在入门对吧然后我当时入门的系统又是一个 Ubuntu 你就会疯狂的去各种搞桌面对一边是学各种命令一边搞桌面然后我印象还挺深的我那时候可能上大一会觉得那个

Ubuntu Tweak 给我带来的各种桌面切换的效果哇 好酷炫然后它进而产生的一个影响是我的摄友发现了之后纷纷开始入门 Linux 因为他们觉得这个东西太酷了就是我的摄友他们的入门方式可能不是说我有需求或者老是说这个东西应该用一下而是说他们发现哇 这个东西太酷了比较酷 对吧然后纷纷的开始对 纷纷开始安装 Linux 然后去尝试使用和学习

其实这个是给我印象很深的当时玩 Linux 能让我留在这个平台上一个很大的原因就是当时确实很酷对啊就是很酷呀所以你就会觉得就是你会带来一种感觉然后会觉得想一直玩下去的感觉

那你真的是我的十年的老用户了应该是应该可能不止十年了吧如果是如果你大一开始用那不大一是什么那就是十年以上的老用户了 10 年的时候还在维护我大概是 12 13 年可能是停止维护的吧

反正有大概积极的做了 5 年左右的开发 5 年以上应该是后面几年基本上就纯维护状态了到现在就是停滞维护了因为我的软件基本上都在终端里面所以我很少用 Mac 的 APP 其实但是我觉得 PaceNow 应该我比较感兴趣一直想试一下

录完我就去试一下因为我们经常需要贴各种命令有的时候你想把那个命令存在剪辑板里或者因为系统剪辑板它只能给你存一个你可能要存很多个我觉得应该可以解决很多的需求对也是满足一个自己这方面的刚才 Adam 不是说用过好几款了

对还有 one switchone switch 对然后其实我用 one switch 可能有一些场景是替代了一些其他的 app 因为我之前有很长一段时间是在家办公对这个时候我就没有了锁屏需求锁屏锁屏不是有个锁屏键吗我记得对

我说的没有锁屏需求是指我不期望电脑我反而不希望电脑锁屏我期望它一直不锁屏明白对我懂了你用了保持亮屏这个开关就只要打开了就始终电脑就亮着了对吧对嗯对然后其实我之前有对我会觉得这两个是比较常用的吧然后 Manico 我印象中我在 15 年还是 16 年有试用过嗯

但是怎么说呢我的习惯在当时可能被 L3 的给养成了就会导致我现在启动 Mac 的 App 可能还是走 L3 的比较多但 L3 你要抢好多键然后 Manicode 你就对 Manicode 是可以快捷键的就是 Command1 Command2 对

我这里可以补充一下那可能说明 Adam 他在使用电脑日常的过程中比较专注他不需要频繁切换像我这样注意力不太集中的人就是写几行代码可能就切到微信或 Telegram 聊天去了然后又切换回来写代码其实我在近几年的思考其实是想到了这个其实 Manicure 是助于我更快的分心的

因为但你用同样用 Effort 的你不可能就是这么去操作嘛因为敲几个字啊什么的还是会麻烦嘛

这是一个题外话没事 随便聊但其实我用 Manicode 最常切换的是 Logsic 做笔记的那个软件比如说我要打电话然后我发现一个什么东西我要写点笔记就会很经常切换然后再 update 一下我的 To Do 之类的所以每个人能从效率中得到的反馈是不一样的

有些人像我后来才知道我其实通过效率得到了更快的摸鱼的反馈但有些人就是比如像 like9m 就会更快的记录自己的笔记或当下计时的想法对吧不好意思能不能介绍一下这个 Manico 是干啥的我对兔拉丁其他的作品都比较了解这个不太了解

我从你们刚刚的描述我也推测不出来这是干啥的其实很简单其实很简单就相当于真的超简单无非就是我可能当时做了一个比较好看的图形和配置界面方便大家去做这件事情了它就是映射一组快捷键到对应的 App 里然后

你只要按下这组快捷键就立刻切换到对应的 APP 然后你再重复按一次就会把当前的 APP 隐藏掉或者就回到上一个 APP 了所以在这种操作你被重复了几次以后你就会养成一个肌肉记忆了

肌肉记忆类似于你在终端里敲一些命令的时候一样但我这个肌肉记忆是在图形的工具里面就是可以快速的完成你想比如在 logsick 里记一点文字你就会下意识的按下这组快捷键在不到一秒的时间内你就切换到这个笔记工具然后去写你想写的东西了类似于这样你不会被其他东西中断

这样应该很容易理解吧其实它是一个很简单的应用只不过我是做了一个图形界面辅助大家养成这个肌肉肌然后一些灵活的配置之类的

我可以从用户角度说一下,就是你想你比如说你现在电脑上可能开了十几个软件嘛,那你最常用的就不用 Alfred 这些,就是用 Command Tab 嘛,Command Tab 按出来它会有可能十几个图标排在那儿,那假设你这个软件是在很右边,你还得把你的鼠标或者触摸板移到右边,这个过程中可能要花费比如说三到五秒,关键它是一个很麻烦的操作嘛,

我觉得你还得想,你要知道它在哪一个地方,你要看着它去,不要老想。对,如果你用 Manico 的话,一个快捷键你想要什么就出来了,然后你最常用的那些,不论它是在 Command Tab 的第几个,你都不需要管,直接一组快捷键它就出来了。我觉得这个是尤其对于这种高频的软件,类似于笔记软件是一个挺强的需求。

OK 我们也是稍微聊了一下自己在用的一些发现还是有用不少的也说明图画顶真的也是开发了相当多帮助大家的软件也是很感谢你对

好 那么其实今天有一个主题是可能以前因为图拉丁也上过一些其他博客节目嘛更多的是聊了一些就是独立开发相关的话题那我们今天可能想从一个比较不一样的角度去聊一下就是

它在独立开发中使用的技术除了我们知道像 iOS Mac 然后 Swift 这些其实很多东西也是需要后端的就像之前说到我不知道你之前提到的就是是一直使用的 Python 对吧对 其实这个也是

我们感觉非常神奇的一点因为像之前看另外一个非常著名的独立开发者八爷可能很多听众都知道他其实也是在一直用 Jungle 作为他的后端的那我就其实非常好奇为什么像你们做独立开发的这些开发者

就纷纷使用 Python 作为后端这个是一种巧合呢还是说是一个就是比较深思熟虑的选择对不如杨武太一你就聊一下就比如说你如何最早接触到 Python 啊然后后来怎么开始使用 Python 开发这些产品呢

可以我觉得我先说结论吧应该是个巧合对我来说是一个巧合因为这个是要回到我刚上大学的时候当时开始接触编程然后我当时在大学肯定是先学 C 语言这种东西然后又同期我开始玩 Linux 了然后当时就想只用 C 写点上然后 Linux 下的图形图形开发框架叫 GTK 然后我当时用 C

C 和 GTK 就开始写 Ubuntu Tweak 的雏形了后来我有印象在一个开源软件的活动上有一个老师他给我推荐了 Python 这门语言说我可以学一下这个说 Python 比较简单那是哪一年呢应该是 2007 年对

好早啊就是刚开始严肃的学编程以及想用编程语言做点严肃的东西的那一年 2000 年然后当时因为无论是中文互联网还是国际互联网其实我自己当时的信息检索能力应该还有限吧

所以就我很快就听从了这位老师的那个意见嘛然后我就开始学一学我就觉得真的很简单然后我觉得 C 语言好麻烦那我就毫不犹豫的就去就是转向用 Python 来实现我的想法了然后具体怎么开始的就是我那个 Ubuntu Tweak 的雏形我还没有写成正式的作品应该是有我当时印象是 0.1 版本我是用 C 语言实现的

然后我的 0.2 版本还是 0.3 版本然后我后面就用 Python 重写了然后因为 Python 这个语言它其实那个时候 15 年前的时候就已经有各种各样的语言 bonding 就是你既可以用来实现就是 web 后端前端前端不行就是可以实现 web 方面的开发

它也有桌面的一些酷的 bonding 所以我当时是用 GTKGTK 这个图形框架当时有个 PYGTKPYGTK 就可以直接用它来去解 Linux 上的桌面工具然后我就很快就在那个 ubuntu tweak 还很小的时候我就果断采用就是 python 重写了一下然后后面就

觉得就真的很好就一直用下去了简单的说我用 Python 就是入了门以后我就是拿它来写图形工具的

跟大多数人的路径应该都不一样大家用 Python 应该会写点 web 相关的东西或者系统级相关的东西但是我是从写图形工具开始的但是同年也看到 Python 的生态其实蛮丰富的然后没记错的话 2007 年是 Jungle 0.96 不止 97 那个时候版本

然后那个时候就是我看到感兴趣的东西都会去学一下然后也就顺便学了 Django 嘛就基于 Python 就学了一下 Django 然后也是边学边做了点东西但那个时候没有用它来做就是让用户用的比如 web 服务一类的当时大概是 08 年的时候用快要 1.0 的 Django 就是开始写自己的 blog 应用

就是以前 blog 是用的 wordpress 后来我觉得 wordpress 有点太笨重了或者用现在比较流行的一句话来说就是每个独立 blog 都想自己发明一套自己的 blog 系统或者去折腾一下这些系统然后我当时也不例外但是我也是真的用 jungle 自己去写了一套 blog 系统然后差不多功能完成以后我就真的把 wordpress 的数据导出来迁到了自己的系统里面去

然后一直用到今年吧反正就现在回头看的话我没有花太多时间在折腾 blog 工具上而是说自己写出了这个工具以后就一直用下来了然后确实也写了写了一些文章可能没那么多嗯

对对对就是用 Python 来写 web 写 blog 系统大概是第二个作品当然我这个没有给就是不是做一个独立的开源的东西就是分享出去用而是我自己用因为我觉得自己用和要做成大众可以用的或者自部署的那些产品的话那就你要耗费的精力就完全不一样了所以这个是我仅限于长期以来都是一种自己用的状态

然后后面其实我也有用 Python 做过一些就是 web 项目是外包的那种比如联系到客户要做一个网站然后我就会肯定会选用 Python 和 Django 做后端的部分然后前端的部分

就会用 vr 之类的这个是外包的一些货对吧就是对对对因为我过去几年也有借过一些外包嘛然后那我肯定选自己熟悉的技术站然后我肯定学 jango 然后 jango 的后台因为比较方便嘛

你稍微定制一下虽然跟真正的那些用户友好的后台相比还有距离但其实大家的要求也没那么高可以蒸 删 查改基本上都 OK 了然后你最多再给客户定制一个副文本编辑什么的其实就完成了一个对吧就完成了一个就是写作后台 CRM 这类的东西所以就一直用的还蛮习惯的但是你说如果是那种

面向大客户或者非常专业的那种的那我觉得 Jungle Admin 又是不够的但目前来说是比较切合我自己的那种需求嗯

差不多吧对我其实学 Django 我是从写自己的博客开始的就博客也是都不能说是一个框架就是用 Django 搭了一个因为我感觉当时搜 Django 的教程很多教程都是包括那个官方教程都是从写一个博客开始对五分钟还是十五分钟写一个 blog 系统是的所以可能很多人都是从这个入门是的

所以很好奇你有没有用起来我其实只我可能真的只在自己博客里用没有在其他项目中用过你说 Jungle 对我说 Jungle 他想问的是你的博客

哦,现在,对,博客一直都是那个呀,就跟你一样,一直都是自己写的东西,我没有用任何的像第三方那种系统。对,那我们这段经历其实是一样的,就是大家在写 Jungle 的过程中用它搭了一个博客系统,然后就一直用到了今天。

对吧是的其实你说这个话题的时候你在说这个是一个有选择的过程还是说比较随意的然后我一开始就回答了这个其实是一个比较随意的不是说是刻意去选择的过程我现在回想可能是运气好或是怎么样假如我那一年那个老师给我推荐了 Ruby 然后我觉得我今年到这个时候

我是会怎么样一个状态或者我的技术战那就肯定是完全就是另外一回事了对吧所以这个真的是一个运气嗯我觉得 Python 的生态在过去 15 年是发展的很好我觉得如果让我认真选择的话如果有机会参考各种语言框架的话我应该还是会选 Python 但你说在你没有各种信息参考的时候真的是靠一个前辈给你指点对吧嗯

所以我现在差不多就这种观点吧就是很多东西其实不是自己做出的选择而是去学习或者听从别人的建议才开始的因为当时我真的什么都不知道那个老师说 Python 不错然后我就跟着去学了就这么简单我觉得很多东西确实

回头看也是非常巧我比较放心一点你现在因为我知道很多你开发的客户端软件实际上是不太需要后端的对吧

对我可以介绍一下我在我的客户端软件里用到的后端部分就是就简单的说虽然我开发的是苹果生态的东西大多数情况下你只需要用到他自己的内购那套系统就是苹果的 IP 支付但过去四年我自己建立起了自己的一套就是

可以说是我自己的内构系统吧相当于我的产品其实不仅仅是在 App Store 上销售的就是说还有在比如少数派数码励志上面也可以独立销售的因为 Mac 应用有这么一个好处就是它跟 iOS 应用不一样你至少是可以独立销售的

但刚开始的时候我是有用第三方的那些比如 license 的生成验证分发的那套系统但是因为用第三方的系统的时候就踩过一些坑然后后来就觉得这种核心的系统还是要自己开发所以在过去三四年我是自己用 Python 开发了一套比如类似于授权码授权机制的这样一套系统也是用 Python 叫 jungle 开发的或者说更细一点的话就是

Jungle 加 REST 那个 framework 其实都是很成熟的那些技术所以我现在的产品其实是虽然说我是客户端产品但我有一些最基本的就是后端的那些需求就是所谓的授权许可系统就是你可以不用在 App Store 上购买

你可以在第三方那些网站上购买然后购买 license 然后打开我的软件用这个 license 去激活然后这个部分其实就是会调用到后端的那些东西了然后就是我的 Python 代码在起作用了差不多就是我目前用的比较多的是应该是这些我听八爷他们好像还有我之前知道的另外像 Tepra 好像他们也是自己用 Python 选择 license 的是吗

我觉得这个也是很常规的一个操作像 license 这种东西你不可能依附于第三方因为我是自己踩过坑所以我后面才坚定要自己开发这样一套系统这个能分享一下主要是什么坑呢还挺好奇的因为之前我有看到像什么 LemonSquid 好像他们宣传看起来都还挺好的因为我没有实际用过

好像他们都会去说自己支持这种好我可以简单分享一下比如我当时文 switch 那款产品最早我这里应该可以提一下这个名字吧没事就是我当时整合的一个叫 devmate 就是这个

授权管理什么系统他当时我会用他主要是他真的做的比较好他提供了 Mac 原生的 SDK 就是包括一个很好用的 web 后端系统然后基本上你就可以开发好你的核心功能以后然后就直接整合这个 SDK 就是从购买销售到激活一条龙都全部可以用它搞定了但是后面

有一年,首先我遇到的第一个问题,我发现他们开发特别慢,你知道苹果每年 MacOS 都会更新一个版本嘛,然后苹果的更新跟 Windows 的更新还是不一样,苹果每年都会带来一些新的 API 的变化,然后你如果老的 SDK 不及时适配的话,它很可能是在新的系统下会工作异常的。

然后当时有一年我发现就是这个 SDK 它更新的非常慢然后我又是个非常追新的人我的产品如果不第一时间适配就是新的操作系统我会比较着急然后当时我就属于比较着急我觉得他们怎么这个适配 SDK 这么慢因为在我的理解里你作为 SDK 的提供商第一时间适配就最新的系统这是一个最基本的任务嘛

不需要你去开发什么新特性但是你的最新系统的基本兼容这肯定是要第一时间做到的但当时这个产品它没有做到然后后面就遇到了更大的一个坑了就是他们直接停止维护了他们转到了一个就是跟已有的用户说他们要停止维护了所以要迁移到什么新的系统去然后应该我们都知道就是后来苹果推出了它自己的 Apple Silicon 平台嘛

然后他们那个 SDK 因为停止维护了,它就长期停留在英特尔平台上了,这就导致我后来维护就是我的产品不得不搞两个就是两个 target,一个就是兼容老的英特尔的,还有一个就是新的,就是我感觉就是还有什么可能,反正就是遇到了好几个问题,这是两个比较典型的。

所以当时我就觉得我下一款产品我绝对不能再用第三方的这种 license 的这个东西了我一定要用自己的

然后就是这样一个契机吧所以这么开发起来的当然第三方做的优秀的应该也不少但是第三方做的优秀的又有这种原生应用 SDK 的我觉得应该是相对来说比较少的你们刚才提到的那些服务我理解应该是应该是基于 web 产品的吧我不知道他们有没有原生 SDK 之类的 web 的居多而且

而且据我所知道第三方的他们的支付结算上面的好像也是挺有问题的其实这里有两个任务都是蛮重的一方面就是支付和结算一方面就是本地 SDK 的那些授权管理这个授权管理你要做得好其实是很难的比如我还可以分享一个点还可以分享一个点就是说

有些产品比如一个 license 支持一台设备的然后假如这个用户联系你他说他的电脑坏了然后要你重新把它的就是 license 给重置一下然后就有些 SDK 他没办法做到把老的设备给自动

反激活就相当于假如他是骗你的他只不过想一个 license 用在多台电脑上这就可以让这个用户就让他可以做到这样我不知道有没有表达清楚就类似于这样

设备管理对他简单的说没做好设备管理他没办法跟踪到底激活了几台设备类似于这样就是一些细节就做的不太好对设备管理感觉挺重要的因为我自己之前没有在 Apple Store 渠道上买然后我找过 Tepra 找过其他好几个开发者就是把我的其他 license deactivate 掉然后就重新激活然后对这个时候就挺麻烦的是的是的是的

所以就是综合各种各样的原因我觉得在某方面做的比较强的可能是有的但是综合所有的做的比较好的现在确实屈指可数但严格来说我自己也小补充一下我自己的产品目前还没有做到设备管理用户假如要反激活的话还是要来联系我的但是我自己的产品有个好处就是说我可以给我

安排这样一个特性开发然后我只要集中时间比如可能一周半个月我就能开发好这样的系统了但是指望第三方的话你是不知道他什么时候能开发好甚至可能永远也不会给你一个就是设备管理这样的一个需求因为我现在本人还没有遇到太多用户要联系我去反激活的这样的一个场景因为我目前还给了用户比较多的设备比如我 PasteNode 是支持

激活舞台设备的嘛就是相对比较宽松嘛所以还没有遇到太多这方面的需求但我是有计划把这些都给做好我说一个很自然的问题就是你打算把这个得做成一个产品吗我觉得是有可能的这个可能在接下去后面的话题会补充一下吧因为我觉得一个系统开发成熟了然后我自己的产品也验证通过了

然后你说那我想做个 SaaS 什么的就是何乐而不为呢当然这可能要投入比较大的精力了这是肯定的因为你只为自己服务和为其他人服务无论是你就各方面要求都肯定会高就像我们前面提到的你给自己做一个 Blog 和做一个 Blog 系统给大家用肯定是两种不一样的要求了对但我不排除未来有这种可能

这个时候就需要说一句我和信涛 report for dutySRE report for duty 记得这样 hire 我明白明白好的好的一定会考虑你们的但前提是我 hire 得起你们

我想问一下这种系统它是怎么做那个管理的就是说它每次打它都需要去联网验证吗还是说它记住了一个什么东西就不需要联网了其实这个就是涉及具体的实现需求了我目前我会至少在 APP 启动的时候进行一次验证然后在每次比如操作系统被换起的时候也会重新验证一下

但我以前用的那些产品是没有这个机制的这个就是看你自己的需求了也可以你激活一次以后永远也不会验证但基本上我觉得在每次重新启动的时候做一个验证这是一个很有必要的吧嗯

那我好奇你们会就是说是会有策略说比如说我验证失败了短时间内可以用如果验证成功就比如说断网的场景转转晚上我在飞机上之后遇到一个场景我的一个专业软件我有就是说是 non-commercial license

但是我发现它在断网的时候没法过验证所以导致说它没法用其实这个我有做我目前不会针对所有比如网络超时之类的做一些比如失败了就直接给当前的状态给清掉了我没有针对这种情况进行严格的那个我只会针对比如 license 已经无效了或超出最大的设备数了类似于做一些

就是说明当前的设备已经无效了类似这样其实还是相对宽松的我没有严格的进行比如你只要验证任何情况下的失败我就给你这台设备设置为无效了我没有做这样的其实

其实这个就是自己的策略了我之前用一个私科的软件 Packet Tracer 它的最新版它的验证它每次打开之后要连网然后有一段时间他们的网站维护挂了维护的时间很恐怖对三四天好像然后你直接软件就不能用了对吧对软件就不能用每次打开的就是说验证失败然后你打开这个网站它网站在维护

那我觉得这个我有考虑的所以我一开始就没有走这么严格的验证甚至我考虑到了就是因为我其实这个验证的服务还是放在国外的就是我考虑到国内的一些用户因为网络不稳定比如各种各样的原因万一哪天被抢了或怎么样了他验证不通过怎么样所以我当时就是做了这种考虑就是如果是任何网络相关的问题我都不会把用户的就是当前的验证设置成无效

OK 好吧这个可能是不是很多处于就是主要客户面向中国用户的开发者都会需要这个需求啊对我觉得可能就是就是假如你至少有一半的用户在中国的话你肯定会把这个场景考虑在内的对吧嗯

所以我觉得你如果解决这个就是一个很解决一个很大的痛点我想到一个问题假如说我在家里然后用我的录音器把那个 DNS 劫持了然后我拿一个有效的 token 去拿到一个有效的回复然后我再把自己劫持这个 DNS 加上一个假的服务器一直返回这个有效的验证这样的话这不是我拿一个在家里用所有的设备都可以把它们激活然后以后永远都不联网了

严格来说肯定是可以的我觉得就是破解的方式有 N 种甚至是可能是长期有效的但是我不打算花精力在这些反破解上因为我觉得你既然有能力破解了你就去破解吧

你这个思路就不对我觉得你改 DNS 不如直接把二进制处理一下因为你改 DNS 你还要搞更正书搞中间人这一套你不搞中间人你怎么伪造小英所以其实破解的方法是有好多种的

对然后先把 iPad 的破解直接修改对直接你修改了然后找个企业证书重新签名当然 for Reco 我们坚决强烈抵制任何破解只是作为技术讨论再讨论理解这些潜在的可能性我都是想过的

对因为我刚才想一个问题就是图拉底刚刚说的服务为什么他们要 SDK 我不太理解为什么不直接提供一个 HTTP 接口对然后让用户自己去实现 HTTP 接口吗

对然后我又突然想到这个问题其实很复杂 SDK 可能要做很多其他的事情是的因为你做客户端应用的话 SDK 它就是会有很多跟除 web 以外的一些考虑就蛮多的这个我在公司正好做相关的一些东西我可以说一下我的观点因为

HTTP 接口它需要暴露的一个东西其实你刚才已经提到了这一点就是 HTTP 接口然后暴露了一个东西就是说你的响应和你的东西如果说把你的响应格式和请求算法就都完整的记录出来那么就会有就是说是被破解

就说基本上就是已经被破解了你找个地方 mock 一个 server 或是其他的这个其实就是常见的因为可能说对于图拉定这样的我个人的产品来说我 case by case 很多人也就没有对我没有太大的兴趣然后我 case by case 的处理这个没有问题

但是如果说我做一个 SaaS 服务服务了成千三百家客户那么如果我统一暴露 HTTP 的 SDK 的话那么就接口让用户自己接入的话那么我就必须把我的签名然后响应等几要数暴露出来这意味着我的用户的安全风险会非常大的所以说这个时候最好的方式就是说暴露混淆过的 SDK 用户直接接入

然后他的 SDK 其实然后这个时候他的定期升级然后这个时候其实是比较稳妥的方式这是经典的一个就说是混淆与不混淆的一个问题其实是这样啊

其实我做这个还没有做到混淆这种级别就是我自己也觉得有很多有待改善的地方就可能到时候以后要向你们请教了图拉顶刚刚提到的这个 SDK 的这个场景我觉得还真的挺有意思的因为我们几个主播的背景都是严格来说都是属于后端的

对那我们开发的应用其实它的运行环境都是可控的就是我们来指定系统版本我们来指定依赖版本对然后我们如何去把它给锁死在各个服务器上去部署但是好像客户端面临的问题就是我只能保证的是我应用的代码和适配性然后新系统一出

老版本的用户也有新版本的也有然后还要做各种适配对可能这个方案就和我们做服务端就很不一样我们可能觉得这个比如说某个依赖它主要是安全稳定可靠的我们就把它锁死在这个版本上然后就用这个依赖

但是好像图阿鼎刚才介绍的情况是我不止有这个需求我还需要他能够尽快的去跟进各种新的这种 API 的适配来保证未来的情况我自己还可以补充一个场景就是

因为桌面端软件或者不管桌面端移动端还有一个场景就是说用户不一定是及时能升级到最新的操作系统也好还是你自己的产品的版本也好这就导致了我的 SDK 必须得

其实不是 SDK,就是 web 那部分其实必须得向后兼容这个其实也是蛮多的工作量的因为不像 web 产品嘛你只要打开今天进入网页了,这肯定是最新的那我今天我的桌面软件发布了 2.0 那 1.0 的用户他的那些验证都要必须还是照常工作的所以这导致了就是

是的就是这是很费力气的嗯就太有体感了对是我的这套 license API 验证机制其实已经迭代了三个版本了但是我得必须保证那个 1.0 的那个对对对都必须还得照常工作就是这个其实是蛮有挑战的但我做的系统都是万无一失的但目前来说还是正常工作中

这个太有感觉了因为像我们之前做因为前段的一些基础测试工作也会在我这边然后我们之前比如说做 API 升级然后做域名切换和其他的时候这个时候就会感叹说用户要是能像我一样没事就升个软件包该多好我们平均一次切换周期完整的切换周期大概是在哪个多三个月接近三个月左右

就因为我们可能还是一个就相对于小领域的专业软件然后我们的一个切换就是其实两个多到三个月才能达到就是说老的客户端旧版本然后差不多 95%的到 98%的流量切到新的版本上就视为一次完整切换我想成为的太难太恶心了

是的,我好奇不能说用户不升级的话你就弹一个框出来说你必须升级才能使用这种是不是会不太好实际上它有可能就不用了这就 suicide 了除非是你跨的版本实在太大了比如说你现在还在用 iOS 6.0

嗯 是这种可以给直接说 iOS6.0 的这个某个版本不做支持了什么请升级什么什么的但大多数情况下你两三个版本就给用户说你必须要升级不升级就不能用那我觉得你这个生意就还不如不做了对对对反正开发原生应用你必须得就是做好这种向后兼容的一些

开发非原生就是 react native 那套也是一样的 react native 其实是原生应用的范畴好吧那也是原生版是是是 OK 反正都是一样的应该说是客户端应用用户可以不依赖网络打开使用类似于这种客户端应用嗯

话说像原生应用里面有没有这种比如说你从服务器上去 Hot patch 一些东西的这种技巧还是说苹果就不让好像游戏只能用在 Mac 上对我理解如果有这种的话那不就其实可以更新一下比如说像

验证这部分但我觉得这样会把事情搞得更复杂对 是的是的我觉得是的对 就你很多时候这个时候第一个是需要原本我可能只是升级一个应用对吧

但是你现在搞了这一回事之后,你可能就需要去,比如说以安卓上面为例,那么你可能说需要把你的功能模块拆得非常的细,做成的不同的 SO,或者说是其他的一些东西,然后能够远程下载,然后 load 进去执行,然后这一套东西你的功能拆细再加上安全可控的风险,

然后这一套弄起来你的做的工作量就可能说比你升级 APP 还要大对对对简单的说对于个人或小团队来做这种 hot patch 成本有点太高了太高了对之前我们研究过类似的方案但是最后说实话没太敢去做因为这个东西说实话有可能会牵扯到法律风险对我是想会不会有一些这种

对就比如说你突然一个单面剧的就像他们玩 hotpatch 的基本都会有出过类似的事就你比如说你把测试的东西不小心推到真实的服务器上去了然后你 patch 了不该 patch 的东西然后这个时候又突然发现他的 app 不能用了那你就寄寄了没事你可以带回来

你可能连就派去那段逻辑都派去掉了对对对有可能很可怕就失控了对然后你在国外可能就会吃集体诉讼了嘛有点嗯

大家要敬意就是说说 HuddlePatchHuddlePatch 对我们就我们之前电源过就彻底放弃了这条路 OK 了解了解我觉得我也不会去尝试这个技术因为我总觉得是一个 workaround 的不如把相互兼容做好不如把 API 设计的时候更加谨慎一点考虑到未来的一些可能性或灵活性或适配度等等是的

OK 对我们其实也聊了一些比较细节的技术我觉得讨论还挺有意思然后想问一下图阿丁有没有什么比如说关于技术选型的想法和建议给到听众们

其实我们之前好像有聊到了就是其实我的技术选型还是挺随意的或者说只是听从前辈或高人的指点来选的然后我可以再其实分享一些我自己其他的一些经历但这些就是属于后面没有继续走下去的那种比如其实我也自己去学过 Ruby 因为我对各种各样的技术还是蛮感兴趣的嘛

我后来也学过 Ruby 也算入门也用 Rios 写过一点点东西但还是没有就是坚持下去一个很重要的原因就是我没有它去做真正在生产环境中使用的东西只是玩完的话就很快就放弃了或者什么没有坚持了其实我也我还有学过 Go 语言我用 Go 写过一些可能是对于

够这种对那种什么高性能啊并发有一些比较适合的场景我有用勾写过其实我当时用勾写的那个服务应该现在还在跑勾的这点一次写好然后后面你再次编译

或部署都基本上不会翻车嗯这点确实做得很好但我也浅尝极致没有好好的去再深入了哦我提了这两点就是我想说就是其实我没有那种很严肃的选行要么就是嗯

学习别人是怎么做的要么就是自己主动去尝试一些或学一些各种各样的技术但一般情况下我觉得一个技术我用的顺手了我就不会再去主动尝试另外一种了比如我几年前第一次接一个不是第一次接应该是反正应该也是后面我一直有间间段段做一些外包项目然后

然后有一天我接了一个外包当时我就想着我不能只是接外包来来完成一个项目而已我应该尝试一些新技术然后那几年 Vivo React 比较火然后我就在想我在后台继续用就是 Django 的前提下我

前端准备尝试一些新的东西然后我是用 view 还是用 react 呢然后当时我应该是问了我的朋友吧比如好像是问了小明我说嗯用 react 还是够然后好像是小明应该他就跟我讲呃就学 view 吧然后就很简单因为朋友在用这个 view 然后我就说好那我就继续 view 然后其实我现在应该但我有段时间没写 view 了但我觉得我如果下一个前端项目我要

选什么的话应该我还是会用 view 然后我不会说去写一个 react 感受一下怎么样因为在同一个领域我觉得有一个东西我用的比较顺手了然后我就继续用下去就行了因为最终的目的是为了做产品嘛不是说为了玩各种各样的技术嗯但你说我对 react 有没有关注过或者稍微了解过这个还是有的但没有用它去做项目嗯也是因为可能几年前嗯

就是比如我前面提到了我学 Ruby 和 Rios 也学过但是为什么没有深入下去是因为没有用它去做项目但假如我有一个项目真的很适合用 React 去写那我应该还是会去去写并用它做出东西的

所以我对自己的这个技术选型和的一个总结就是说可能看看比你专业的朋友或者说有经验的前辈也好或者是高手也好他们在用什么就是简单的说找到一个你的榜样他在用什么然后你就先跟着他去学呗嗯

至于自己能不能在没有一点基础的情况下去选择或做出一个很好的选择我觉得应该不太可能因为你在没有任何尝试过的前提下就做出一个就是说给自己做出一个很合适的选择我觉得应该还是比较难的至少我目前的经历就是这样

包括我在客户端开发的一些经历也可以分享如果大家关注我的 Twitter 或者 X 就知道其实我经常会吐槽 Swift UI 那是因为其实 Swift UI 是一个 Apple 原生开发的一个新技术然后

他是确实是很新之前也没有什么经验可以参考我相当于是第一批学习并实践的人就是是完全自己摸索着过来的所以我知道他有哪些缺点和哪些优点嗯

我也是完全自己踩了各种坑的情况下才知道它的适用环境就是说在接触全新东西的时候你肯定只能自己去尝试去做点什么你才能知道它好还是坏但一个东西相对比较成熟了那你就去学习那些你觉得是榜样的人他们怎么用就可以了对吧我的总结应该就是这样

对我觉得你提到一个很好点就是经常被忽视就是看一下你熟悉的人或者你想学习的人他们在用什么因为他们形象已经帮你做过一次筛选了

但是我身边的熟悉的人两边都在打架当我每次想重新递一百次入门前端的时候你认识的人太多了我身边的人我觉得你认识的人太多太多会导致选择困难关系好的就一边拉着我去学 react 告诉我 react 是世界主宰一边让我去学 voereact 然后当然还有一小波我真的有一小波是 angular 的信条 angular 那套信条天哪还有 angular

那你真的面临的选择太多了对然后反正是我在一个群然后就是叫做叫 Saka 学前端的群然后每一天然后说一下我先去现场然后我先撤下然后我对我本身今天是没法来的然后但是我觉得我还是得实在来见一下特拉丁本人见到之后心满意足了下次来找你签名来了不用太夸张了

我对你一直是我是你的老粉然后对然后你在 Centralf 上面上线的那个因为我也在用挺好用的那就是 WinSwitch 了我知道对 OK 那我先撤了抱歉了各位台康加油台康加油再见拜拜

拜拜拜拜拜拜对其实因为这次我们正好聊 Jungle 我觉得还是有必要推荐一下一个特别适配 Jungle 的前端轻量级框架就是 HTMX 不知道你听说过没有

我不仅听说过我上周还收藏了一篇文章我看了一下他的一个 demo 我觉得我可能会尝试用它因为好像真的很不错他那个是我也是在打算在我项目里尝试因为他就真的非常轻量级而且他就是没有什么像 virtual dom 这种东西就是

一个属性对吧然后是的而且它跟 Jungle 的模板适配的特别好所以其实它在国外的 Jungle 圈子里面或者甚至包括整个用 Python 作为后端语言的圈子里是现在越来越火了

是的虽然我的目前的主要精力是放在原生应用的开发上但是其实我还是会时不时接触一下这些 web 领域的一些东西的我觉得你刚刚提到的是 html x 就叫 htm x 把那个 lt 换成 x 对对对

HTMX 但实际上刚刚我说 HTMX 也是说的这个他们是不是也买了一个类似的这种关键词应该不是应该下火了吧我可以描述一下我看到的那个 demo 那篇文章讲的是什么就是大概是一个表单然后它可以很好的就结合起来相当于

就跟 Drango 的那个 template 然后和他的那个表单包括一些都无分的整合了起来就真的很

我一看就懂,然后就觉得很优雅的解决了一个问题,然后就有那种去尝试的想法和欲望,然后没有任何前端的那些负担,就纯前端框架的那些负担。对,我觉得你用 Vue 或者 React,你实际上你都不能用像 Jungle 的模板这一套东西了,然后你实际上是前端完全重新起一套东西。

对如果之后我觉得我再有一些使用经验也可以再聊一下这个我觉得挺有意思可以多多分享好还有一个想请教图拉鼎的点就是因为像做这种个人开发者涉及到的技术选型可能比如说只是我个人理解就不太能参考像这种业界大公司的工程博客因为他们可能面临的体量问题和

我们要解决问题完全不一样对那这种时候可能比如说一般就除了从朋友这边获取信息还会怎么样去获取一些这种适用于个人开发者的一些技术战案或者是技术信息对就是你的意思是假如身边也没有朋友可以参考的话然后大公司的那些案例又没办法办到就是个人的这种情况下对吧对的

或者说这个可能不太像一个我有一个问题我是主动解决方案而是指比如说像我日常可能会订阅很多工程博客但是他可能很多其中一大部分占比都是这种公司级别的嗯

对然后再以及就是个人分享对就某一些工程师的博客他会我最近解决什么问题用了什么站对那比如说就是你会去比如说订阅一些个人独立开发这种的博客或者是其他之类的信息吗嗯

我肯定会看各种各样的比如 newsletter 但是你涉及到具体的问题解决假如没有身边的人和就是大公司的经验可以学习好像除了自己亲自去尝试也没有什么其他办法

反正肯定会踩很多坑吧最好用一个具体的问题来引入因为我觉得感觉比较大这个东西比如你遇到过什么问题然后我可以想想我有没有类似的问题遇到过然后我是怎么去解决或者找解决办法的你有具体的案例可以引出这个话题吗我觉得这个可能不太像具体案例吧就是我举一些例子就比如说可能我有一个业余的项目对

然后有具体的问题那可能 Google 或 ChatGPT 是能够帮到我的但是很多时候我可能并不知道有业界有哪些酷或者是有哪些这种这种好用的工具是不是就是我不知道我

我不知道不知道什么东西对就是对就是比如说我最近在做一个这种 web 的东西我需要写一个界面但是像我这种后端研发来说 CSS 这个东西是我的很苦恼的东西就是其实一个是 CSS 另外一个就涉及到审美就是

你如果没有这两个就很难写出漂亮的但是比如说有经验的朋友他会直接推荐我 tellwind 对这种类似的东西然后我就发现哇就直接解决了我的问题我不需要从头搞但是这个事情就变成了朋友间的口口相传就好像我自己搜我不太见得能

准确的找到这个东西可能我如果我自己去做就变成了我先去搜如何做设计如何做网页然后如何写 CSS 一步步的从零到一搞出来但是其实可能真实的解决方案最好的可能不是这个样子嗯

那我觉得其实这个问题我也没有很好的解法还是得问人问足够多的问足够多的我其实有个技巧就是你在推特上发一个引战帖比如说我觉得 Vanilla CSS 是最好的 CSS 然后底下人就会各种给你推荐为什么为什么别的 CSS 框架更好然后对就是很多很多

总的来说我觉得解决办法就是说你不能只是自己瞎折腾就自己一个人去找你的答案肯定是要把答案抛出去要把问题抛出去无论是抛给谁抛的越多你肯定是越能接近你想要的答案对吧

LexiM 刚刚说的那个不是论坛时代的小技巧吗什么注册个马甲引战一下然后就会有人主动跳出来给你详细的说明通用的嘛就你注册个马甲就是说一个很傻逼的帖子就是明显是错误的然后对吧这会比你发一个正向的帖子去吹一个东西吸引来更多的流量以及在大多数情况下更有价值的内容

不是唯一的方法但是我没尝试过我一定要有个想法

OK 我是这样想我想我们先就录完这个先暂停一下然后我去开另外一个录音房间我们录下一段因为这样的话到时候剪辑会比较方便就是我们有一个开始然后我想已经有一些小时了对吧可以对我想把它剪成两期对好那我就听众们就我们先就是先下然后之后会开新的来录下一期好我们先就拜拜嗯