#数据库
#时序数据库
#播客
《【技术科普】从Greptime聊时序数据库》
Greptime创始人聊了时序数据的特点、时序数据库与通用数据库的区别、使用Rust来编写基础软件的原因,等等,是一期不错的时序数据库科普播客。
另外,我也同意所谓“研发效率”不应该局限在研发阶段,应该放得更远扩充到查问题阶段。比如以前写过的一期博客《线上存储服务崩溃问题分析记录》,里面提到因为C的内存问题查了一个多礼拜,由于都在查问题显然影响了我做研发的时间。所以像Rust这样的语言,能够把大部分内存安全问题在编译阶段就解决掉,这也提升了“研发效率”,见:《一个C系程序员的Rust初体验》。
#时序数据库
#播客
《【技术科普】从Greptime聊时序数据库》
Greptime创始人聊了时序数据的特点、时序数据库与通用数据库的区别、使用Rust来编写基础软件的原因,等等,是一期不错的时序数据库科普播客。
另外,我也同意所谓“研发效率”不应该局限在研发阶段,应该放得更远扩充到查问题阶段。比如以前写过的一期博客《线上存储服务崩溃问题分析记录》,里面提到因为C的内存问题查了一个多礼拜,由于都在查问题显然影响了我做研发的时间。所以像Rust这样的语言,能够把大部分内存安全问题在编译阶段就解决掉,这也提升了“研发效率”,见:《一个C系程序员的Rust初体验》。
Xiaoyuzhoufm
【技术科普】从Greptime聊时序数据库 | DevmoreWork
听《迪魔王 Devmore - More about Dev》上小宇宙。 比起有意义,有趣的事才会坚持下去呀。
这里是迪魔王电台,Devmore,让有意义的事情有意思。
【DevmoreWork】more about work,侧重专业的职场话题,邀请行业专业嘉宾,为大家带来更多专业方向的知识和参考。
【DevmoreLife】是技术生活系列,技术源于生活,又归于生活,该系列跟你聊一聊生活中无处不在的技术。
【MeetDevmore】meet with us,围绕某一个话题,邀请嘉宾和听众们边吃…
这里是迪魔王电台,Devmore,让有意义的事情有意思。
【DevmoreWork】more about work,侧重专业的职场话题,邀请行业专业嘉宾,为大家带来更多专业方向的知识和参考。
【DevmoreLife】是技术生活系列,技术源于生活,又归于生活,该系列跟你聊一聊生活中无处不在的技术。
【MeetDevmore】meet with us,围绕某一个话题,邀请嘉宾和听众们边吃…
👍4
#杂
“亲眼看着 databend/datafuse/fuse-query 先从豆瓣广播上的一个个想法变成了代码然后变成了产品最后变成了公司,当时还是豆瓣广播重度用户的我天天在豆瓣广播上追 @BohuTANG
的关于数据库的想法,时隔几年后偶然在 GitHub 上看到了 databend,还是很震惊的”
https://twitter.com/yetone/status/1697072792305610931
“亲眼看着 databend/datafuse/fuse-query 先从豆瓣广播上的一个个想法变成了代码然后变成了产品最后变成了公司,当时还是豆瓣广播重度用户的我天天在豆瓣广播上追 @BohuTANG
的关于数据库的想法,时隔几年后偶然在 GitHub 上看到了 databend,还是很震惊的”
https://twitter.com/yetone/status/1697072792305610931
👍13❤2
#文章
《恒纪元与乱纪元》,很棒的一篇文章,以时间为纵轴,横向对比了从16世纪大航海时代以来东西方的历史和文明进程,列举了自那以来的数个大分裂、大发展时代及其原因,要是有视频结合着文章解读就更好了。
按照文章的说法,最后一次恒纪元是1992-2017年,做为80后的一代,成长的年代完全赶上了这个纪元。按说我们应该就是那波吃到时代红利的人,可在我20多岁的时候,当时经常想的是:父母那代人(50后)因为时代的原因没有得到很好的教育、到了工作后在90年代又面临着下岗、自己这代人则是初代独生子女、读大学开始涨价、房价开始飞起....所谓时代红利,这都是后话,当时身处其中,一样也对社会有很多的迷茫、不满,看来每代人在这个年纪的状态都是差不多的。我到了现在这个年纪再回头去看,从1840年鸦片战争之后的中国近代史,我们这代人没有赶上战争、大饥荒、国家剧烈动荡等,还赶上了改革开放国家大发展,确实是运气很好的一代人了。
以文中的划分,当前处于从2018年中美贸易战开始之后的一次乱纪元,所谓“百年未有之大变局”,吃上时代红利的我,人到中年也赶上了这次乱纪元,就我个人而言,暂时能想到的办法不多,目前大的方向是:多屯粮(存钱)、去杠杆(最近还了一波房贷)。
《恒纪元与乱纪元》,很棒的一篇文章,以时间为纵轴,横向对比了从16世纪大航海时代以来东西方的历史和文明进程,列举了自那以来的数个大分裂、大发展时代及其原因,要是有视频结合着文章解读就更好了。
按照文章的说法,最后一次恒纪元是1992-2017年,做为80后的一代,成长的年代完全赶上了这个纪元。按说我们应该就是那波吃到时代红利的人,可在我20多岁的时候,当时经常想的是:父母那代人(50后)因为时代的原因没有得到很好的教育、到了工作后在90年代又面临着下岗、自己这代人则是初代独生子女、读大学开始涨价、房价开始飞起....所谓时代红利,这都是后话,当时身处其中,一样也对社会有很多的迷茫、不满,看来每代人在这个年纪的状态都是差不多的。我到了现在这个年纪再回头去看,从1840年鸦片战争之后的中国近代史,我们这代人没有赶上战争、大饥荒、国家剧烈动荡等,还赶上了改革开放国家大发展,确实是运气很好的一代人了。
以文中的划分,当前处于从2018年中美贸易战开始之后的一次乱纪元,所谓“百年未有之大变局”,吃上时代红利的我,人到中年也赶上了这次乱纪元,就我个人而言,暂时能想到的办法不多,目前大的方向是:多屯粮(存钱)、去杠杆(最近还了一波房贷)。
❤11👍1👎1
#杂
#人工智能
闲聊我对人工智能的看法,由于不是这个方向的从业人员,可能会有误。
人工智能技术发展的三个要素,在我看来:算法、算力、数据(场景)。
先说算法。我感觉在现在论文、开源项目满天飞的情况下,算法是最容易取得突破的。OpenAI是先行者,所以后来进入这个领域的项目,就需要以开源的形式来快速获取信任以及借助开源社区来加快技术的迭代。
再说算力。算力是可以靠钱来堆的,只不过现在人工智能领域的算力门槛太高,起步就要动辄大几十亿的硬件(主要是GPU)成本开销,但是总的来说事情能靠砸钱解决的话,问题不算大。
最后说数据。我认为数据是这里面最难积累的一个,因为需要大量的数据来训练模型,这就需要数据提供方提供出来,推特最近已经禁止第三方API了,这有点像当年淘宝做电商的时候直接屏蔽搜索引擎的爬虫。数据还有一个难点,是需要“与时俱进”,如果用截止到2016年的数据训练出来的模型,想回答今天的问题,恐怕是不太精准的。
综上,这三个要素中从突破的难度来看,算法<算力<数据,OpenAI在刚开始起步时能拿到数据来训练它的通用模型,但是现在大家都在打明牌了,后期还能不能拿到这么多数据,存疑。所以我还是更看好那些掌握大量数据的社交媒体、搜索引擎公司,这样的公司有人也有钱,突破前两点难度不大,第三点可以通过封闭数据开放来建立自己的壁垒。
前几年大数据刚开始火的时候,有一句话说的是“数据就是这个时代的石油”,几年之后来到新的人工智能时代,这句话的重要性越发凸显了。从另外一点也可以看出来:中美双方都要求对方的企业把数据存储在本国,如苹果中国区的数据存在云上贵州,Tiktok美国区也要用的美国的存储服务,除了数据安全考量,还有的就是数据的“石油”属性:越掌握数据的人,才会越懂人的行为。
#人工智能
闲聊我对人工智能的看法,由于不是这个方向的从业人员,可能会有误。
人工智能技术发展的三个要素,在我看来:算法、算力、数据(场景)。
先说算法。我感觉在现在论文、开源项目满天飞的情况下,算法是最容易取得突破的。OpenAI是先行者,所以后来进入这个领域的项目,就需要以开源的形式来快速获取信任以及借助开源社区来加快技术的迭代。
再说算力。算力是可以靠钱来堆的,只不过现在人工智能领域的算力门槛太高,起步就要动辄大几十亿的硬件(主要是GPU)成本开销,但是总的来说事情能靠砸钱解决的话,问题不算大。
最后说数据。我认为数据是这里面最难积累的一个,因为需要大量的数据来训练模型,这就需要数据提供方提供出来,推特最近已经禁止第三方API了,这有点像当年淘宝做电商的时候直接屏蔽搜索引擎的爬虫。数据还有一个难点,是需要“与时俱进”,如果用截止到2016年的数据训练出来的模型,想回答今天的问题,恐怕是不太精准的。
综上,这三个要素中从突破的难度来看,算法<算力<数据,OpenAI在刚开始起步时能拿到数据来训练它的通用模型,但是现在大家都在打明牌了,后期还能不能拿到这么多数据,存疑。所以我还是更看好那些掌握大量数据的社交媒体、搜索引擎公司,这样的公司有人也有钱,突破前两点难度不大,第三点可以通过封闭数据开放来建立自己的壁垒。
前几年大数据刚开始火的时候,有一句话说的是“数据就是这个时代的石油”,几年之后来到新的人工智能时代,这句话的重要性越发凸显了。从另外一点也可以看出来:中美双方都要求对方的企业把数据存储在本国,如苹果中国区的数据存在云上贵州,Tiktok美国区也要用的美国的存储服务,除了数据安全考量,还有的就是数据的“石油”属性:越掌握数据的人,才会越懂人的行为。
👍15
#Rust
JetBrains发布独立的Rust IDE RustOver:《Introducing RustRover – A Standalone Rust IDE by JetBrains》,之前要在JetBrains系的IDE写Rust都是走插件的路线,现在终于出了一个独立的产品。
像JetBrains这样专业做开发者工具(IDE)的公司,必然掌握了很多开发者的统计数据,衡量一个语言的流行度,有不同的数据维度,比如社区的活跃度、开源项目的数量、搜索的数量等等。商业开发工具的数量、质量也应该是一个维度,因为商业公司要为之开发新产品,这背后肯定需要数据的支撑才行。
JetBrains发布独立的Rust IDE RustOver:《Introducing RustRover – A Standalone Rust IDE by JetBrains》,之前要在JetBrains系的IDE写Rust都是走插件的路线,现在终于出了一个独立的产品。
像JetBrains这样专业做开发者工具(IDE)的公司,必然掌握了很多开发者的统计数据,衡量一个语言的流行度,有不同的数据维度,比如社区的活跃度、开源项目的数量、搜索的数量等等。商业开发工具的数量、质量也应该是一个维度,因为商业公司要为之开发新产品,这背后肯定需要数据的支撑才行。
The JetBrains Blog
Introducing RustRover – A Standalone Rust IDE by JetBrains | The RustRover Blog
“When will there be a Rust IDE?” We get this question from our users quite frequently, and today we’re happy to announce that the day has arrived. Please welcome RustRover, our standalone IDE for R
👍18🥰2
#世界观
小时候学到“刻舟求剑”这个成语的时候,觉得世界上怎么会有这么蠢的人,会认为过了一段时间回去河里找剑,剑还停在原位置。
刻舟求剑的本质,在我看来是:没有随着时间更迭自己的观念。有了这个概念之后回头再看,现实生活里不少人会刻舟求剑,比如很多人喜欢用现在的技术、观念去认为按照目前这个程度持续下去未来就会如何如何。
引发我思考这类”泛刻舟求剑“现象,是因为最近生育率下降,不少人会悲观得认为以现在的生育率下出生的人口,未来等到这批人做为养老主力军的时候养老负担很大。这类观点的问题在于,只考虑了出生人口和养老人口这两个维度,有没有可能几十年过去后,生产力更高,或者出现了新的辅助养老工具(如机器人AI)等,让单人的养老负担变得比现在更小?如果这些因素发生了变化,那么前面得到的结论,不就是一个类”刻舟求剑“的思路吗。
与“刻舟求剑”相对应的,我认为是“与时俱进”:只要时间变化,任何维度(生产力、生产关系,etc.)都可能发生变化,时间才是让事情发生改变的容器。
小时候学到“刻舟求剑”这个成语的时候,觉得世界上怎么会有这么蠢的人,会认为过了一段时间回去河里找剑,剑还停在原位置。
刻舟求剑的本质,在我看来是:没有随着时间更迭自己的观念。有了这个概念之后回头再看,现实生活里不少人会刻舟求剑,比如很多人喜欢用现在的技术、观念去认为按照目前这个程度持续下去未来就会如何如何。
引发我思考这类”泛刻舟求剑“现象,是因为最近生育率下降,不少人会悲观得认为以现在的生育率下出生的人口,未来等到这批人做为养老主力军的时候养老负担很大。这类观点的问题在于,只考虑了出生人口和养老人口这两个维度,有没有可能几十年过去后,生产力更高,或者出现了新的辅助养老工具(如机器人AI)等,让单人的养老负担变得比现在更小?如果这些因素发生了变化,那么前面得到的结论,不就是一个类”刻舟求剑“的思路吗。
与“刻舟求剑”相对应的,我认为是“与时俱进”:只要时间变化,任何维度(生产力、生产关系,etc.)都可能发生变化,时间才是让事情发生改变的容器。
❤23👍5💩4
#杂
混迹在张银奎老师的微信群里,看到一则讣告:
“
讣告
万分难过,吴岩峰(syserdebugger 作者),我们的峰子,因为意外受伤后抢救无效,于2023年9月23日在北京离开了我们,终年47岁,走过了他短暂却精彩的一生,我们怀着无比沉痛的心情哀悼他的离去,同时,向所有爱他的、关心他的人报以最真挚的感激!
愿天堂没有意外,一路走好,我们的峰子!
兹定于9月27日上午9时,在东郊殡仪馆祥鹤厅举行告别会。
谨此讣告。
”
由于不是这个技术方向,所以对这个作者并不了解,搜索到的一篇文章《致青春,基础软件开发的中国故事》介绍了他们做的事情。
回到20年前的2003年,那个年代没有什么stackoverflow、github这类供程序员交流的平台,面对Windows这样封闭的系统,也没有很多内核级别的资料,要写一个windows的内核调试器,难度可想而知,我至今都很好奇像 softice、trw 这样的软件90年代时是怎么写出来的。
由于工作的关系,现在我也在基础软件领域工作了,现在中国基础软件领域的工作机会、资料比当年都多了很多,身边能接触很多95年甚至2000年以后出生的人,这一代人能接触到的信息、知识面等等都比当年同年龄的我强很多的,还是很羡慕他们的。
混迹在张银奎老师的微信群里,看到一则讣告:
“
讣告
万分难过,吴岩峰(syserdebugger 作者),我们的峰子,因为意外受伤后抢救无效,于2023年9月23日在北京离开了我们,终年47岁,走过了他短暂却精彩的一生,我们怀着无比沉痛的心情哀悼他的离去,同时,向所有爱他的、关心他的人报以最真挚的感激!
愿天堂没有意外,一路走好,我们的峰子!
兹定于9月27日上午9时,在东郊殡仪馆祥鹤厅举行告别会。
谨此讣告。
”
由于不是这个技术方向,所以对这个作者并不了解,搜索到的一篇文章《致青春,基础软件开发的中国故事》介绍了他们做的事情。
回到20年前的2003年,那个年代没有什么stackoverflow、github这类供程序员交流的平台,面对Windows这样封闭的系统,也没有很多内核级别的资料,要写一个windows的内核调试器,难度可想而知,我至今都很好奇像 softice、trw 这样的软件90年代时是怎么写出来的。
由于工作的关系,现在我也在基础软件领域工作了,现在中国基础软件领域的工作机会、资料比当年都多了很多,身边能接触很多95年甚至2000年以后出生的人,这一代人能接触到的信息、知识面等等都比当年同年龄的我强很多的,还是很羡慕他们的。
Wikipedia
SoftICE
kernel mode debugger
❤2👍1
#编程语言
Daniel P Friedman在编程语言界的贡献
转自微博:https://m.weibo.cn/status/4952639604523552
因为最后一段文字,特地找了王垠的两篇文章:
* 《写小人书的老顽童》
* 《Chez Scheme 的传说》
------ 分割线,以下为原文 ------
绝对是今年计算机专业的一件大事。Daniel P Friedman,79岁高龄,在2023年出版了他的The Little ... 系列的新书,The Little Learner。
老爷子是Lazy Evaluation的发明者,Scheme届一哥,发明Scheme的人都亲口承认这一点;现在还在Scheme届抗梁的人物,除了UBC那个发明Aspect Oriented Programming、MIT肄业、Xerox Parc精英Gregor Kiczales之外,全是Friedman的徒子徒孙;因为Scheme是最接近Lambda的语言,所以Friedman可以理解为能写『顶尖』代码的Church。『顶尖』二字在这里的意思不但指它在学术界的编程能力是顶流,他给Scheme语言留下的诸如Pattern Matching宏代码可以正面刚Kernel里的所有工业代码。
不止Scheme语言教学。Friedman的同事,另一个传奇人物Kent Dybvig,写了工业级的Scheme语言编译器,Chez Scheme,包括Cisco在内的很多大企业都是他的客户。Chez Scheme后来出现了开源的版本,在这个版本里Friedman和Dybvig合作了被称为nanopass的编译器框架;虽然Scheme不是流行的工业语言,但是两个版本的Chez Scheme在编译速度和执行速度上都可以跟任何工业级语言编译器抗衡;而且Chez Scheme自带的解释器,性能高达编译器的1/2.5的水平,想想v8出现时直接把JavaScript速度提高了1000-5000倍,这个名称为Petite Chez Scheme的解释器毫无疑问是性能最好的编程语言解释器。
远不只这些。
The Little Typer,是介绍Dependent Types的入门书籍,提供了仅6000行代码实现的Pie语言;任何人都可以从这里开始了解现代计算机语言的类型系统。
The Little Prover,通过ACL2定理证明器讲解现代定理证明器使用。
The Reasoned Schemer,仍通过Scheme语言讲解relational logic和logic programming。这本书神奇的出到了第二版,令人匪夷所思,因为这实在是非常冷门的领域。该书的第二作者William E. Byrd是Friedman的学生,他在Youtube上有故弄玄虚的视频讲解他当年看到Friedman的代码时,是如何获得了被天打雷劈的感受的。
++++
以上都是符号主义在编程领域的巅峰之作。
我承认我会因为Frank Pfenning(Peter Andrews的学生,Alonzo Church的徒孙),Robert Harper(Robert Constable的学生,Stephen Cole Kleene的徒孙,Alonzo Church的曾徒孙),Steve Awodey(Saunders Mac Lane的学生,Mac Lane是Weyl和Bernays的学生,前者是Hilbert的学生,后者是Landau的学生)等人的学术成就,把他们的学术水平看在Friedman之上,这三个人是cmu三剑客,活跃在youtube上的oplss频道,讲解constructive logic, type theory和category theory。但是如果没有Friedman,你将只会淹没在符号和数学里,远没有现在这样容易只通过一种语言了解计算机科学的如此广阔的领域。
而他在79岁这一年,出版了The Little Learner,关于Deep Learning,给这本书写序的人是MIT的Guy Lewis Steele Jr.(Gerald Jay Sussman的学生)和Peter Norvig(人工智能:一种现代方法的两个作者之一)。
无法表达对老爷子的敬佩之情,不把这些书的习题都做了,都对不起他老人家。
++++
王垠写过不少盛赞Dybvig和Friedman的文字,他是令人羡慕的看见过光的人,但不知道为什么他拿着手电筒离开了印第安纳。
Daniel P Friedman在编程语言界的贡献
转自微博:https://m.weibo.cn/status/4952639604523552
因为最后一段文字,特地找了王垠的两篇文章:
* 《写小人书的老顽童》
* 《Chez Scheme 的传说》
------ 分割线,以下为原文 ------
绝对是今年计算机专业的一件大事。Daniel P Friedman,79岁高龄,在2023年出版了他的The Little ... 系列的新书,The Little Learner。
老爷子是Lazy Evaluation的发明者,Scheme届一哥,发明Scheme的人都亲口承认这一点;现在还在Scheme届抗梁的人物,除了UBC那个发明Aspect Oriented Programming、MIT肄业、Xerox Parc精英Gregor Kiczales之外,全是Friedman的徒子徒孙;因为Scheme是最接近Lambda的语言,所以Friedman可以理解为能写『顶尖』代码的Church。『顶尖』二字在这里的意思不但指它在学术界的编程能力是顶流,他给Scheme语言留下的诸如Pattern Matching宏代码可以正面刚Kernel里的所有工业代码。
不止Scheme语言教学。Friedman的同事,另一个传奇人物Kent Dybvig,写了工业级的Scheme语言编译器,Chez Scheme,包括Cisco在内的很多大企业都是他的客户。Chez Scheme后来出现了开源的版本,在这个版本里Friedman和Dybvig合作了被称为nanopass的编译器框架;虽然Scheme不是流行的工业语言,但是两个版本的Chez Scheme在编译速度和执行速度上都可以跟任何工业级语言编译器抗衡;而且Chez Scheme自带的解释器,性能高达编译器的1/2.5的水平,想想v8出现时直接把JavaScript速度提高了1000-5000倍,这个名称为Petite Chez Scheme的解释器毫无疑问是性能最好的编程语言解释器。
远不只这些。
The Little Typer,是介绍Dependent Types的入门书籍,提供了仅6000行代码实现的Pie语言;任何人都可以从这里开始了解现代计算机语言的类型系统。
The Little Prover,通过ACL2定理证明器讲解现代定理证明器使用。
The Reasoned Schemer,仍通过Scheme语言讲解relational logic和logic programming。这本书神奇的出到了第二版,令人匪夷所思,因为这实在是非常冷门的领域。该书的第二作者William E. Byrd是Friedman的学生,他在Youtube上有故弄玄虚的视频讲解他当年看到Friedman的代码时,是如何获得了被天打雷劈的感受的。
++++
以上都是符号主义在编程领域的巅峰之作。
我承认我会因为Frank Pfenning(Peter Andrews的学生,Alonzo Church的徒孙),Robert Harper(Robert Constable的学生,Stephen Cole Kleene的徒孙,Alonzo Church的曾徒孙),Steve Awodey(Saunders Mac Lane的学生,Mac Lane是Weyl和Bernays的学生,前者是Hilbert的学生,后者是Landau的学生)等人的学术成就,把他们的学术水平看在Friedman之上,这三个人是cmu三剑客,活跃在youtube上的oplss频道,讲解constructive logic, type theory和category theory。但是如果没有Friedman,你将只会淹没在符号和数学里,远没有现在这样容易只通过一种语言了解计算机科学的如此广阔的领域。
而他在79岁这一年,出版了The Little Learner,关于Deep Learning,给这本书写序的人是MIT的Guy Lewis Steele Jr.(Gerald Jay Sussman的学生)和Peter Norvig(人工智能:一种现代方法的两个作者之一)。
无法表达对老爷子的敬佩之情,不把这些书的习题都做了,都对不起他老人家。
++++
王垠写过不少盛赞Dybvig和Friedman的文字,他是令人羡慕的看见过光的人,但不知道为什么他拿着手电筒离开了印第安纳。
m.weibo.cn
微博
随时随地发现新鲜事!微博带你欣赏世界上每一个精彩瞬间,了解每一个幕后故事。分享你想表达的,让全世界都能听到你的心声!
👍9❤3
#效率工具
发现微信读书的一个神功能,使用”传书到手机“上传一个英文书的PDF,会自动帮你翻译成中英文一起的电子书,大大提升了阅读速度。
比如我上传了EOPL,效果如图所示。
除此以外,上传到微信读书,相当于自带了”云端同步“,随时多设备打开同步阅读进度了。
发现微信读书的一个神功能,使用”传书到手机“上传一个英文书的PDF,会自动帮你翻译成中英文一起的电子书,大大提升了阅读速度。
比如我上传了EOPL,效果如图所示。
除此以外,上传到微信读书,相当于自带了”云端同步“,随时多设备打开同步阅读进度了。
❤14👍1
#杂
#开源
得到已故中国顶级黑客吴岩峰先生的夫人的授权,将syserdebugger源码开放,欢迎大家继续开发:https://github.com/yanfengwu-syser/syserdebugger
Reference:https://t.me/codedump_notes/474
#开源
得到已故中国顶级黑客吴岩峰先生的夫人的授权,将syserdebugger源码开放,欢迎大家继续开发:https://github.com/yanfengwu-syser/syserdebugger
Reference:https://t.me/codedump_notes/474
GitHub
GitHub - yanfengwu-syser/syserdebugger
Contribute to yanfengwu-syser/syserdebugger development by creating an account on GitHub.
👍12
#编程
Rob Pike's 5 Rules of Programming
Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
规则 1:你无法判断程序将把时间花在哪里。瓶颈出现在令人惊讶的地方,因此,在证明瓶颈所在之前,不要尝试再次猜测并进行速度修改。
Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms
the rest.
规则 2. 测量。在测量之前不要调整速度,即使这样,除非代码的一部分压倒了其余部分,否则也不要调整速度。
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
规则 3:当 n 很小时,花哨的算法会很慢,而且 n 通常很小。奇特的算法有很大的常数。在您知道 n 通常会很大之前,不要幻想。 (即使 n 确实变大,也首先使用规则 2。)
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
规则 4:花哨的算法比简单的算法更容易出错,而且更难实现。使用简单的算法和简单的数据结构。
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
规则 5:数据占主导地位。如果您选择了正确的数据结构并很好地组织了事物,那么算法几乎总是不言而喻的。编程的核心是数据结构,而不是算法。
Rob Pike's 5 Rules of Programming
Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.
规则 1:你无法判断程序将把时间花在哪里。瓶颈出现在令人惊讶的地方,因此,在证明瓶颈所在之前,不要尝试再次猜测并进行速度修改。
Rule 2. Measure. Don't tune for speed until you've measured, and even then don't unless one part of the code overwhelms
the rest.
规则 2. 测量。在测量之前不要调整速度,即使这样,除非代码的一部分压倒了其余部分,否则也不要调整速度。
Rule 3. Fancy algorithms are slow when n is small, and n is usually small. Fancy algorithms have big constants. Until you know that n is frequently going to be big, don't get fancy. (Even if n does get big, use Rule 2 first.)
规则 3:当 n 很小时,花哨的算法会很慢,而且 n 通常很小。奇特的算法有很大的常数。在您知道 n 通常会很大之前,不要幻想。 (即使 n 确实变大,也首先使用规则 2。)
Rule 4. Fancy algorithms are buggier than simple ones, and they're much harder to implement. Use simple algorithms as well as simple data structures.
规则 4:花哨的算法比简单的算法更容易出错,而且更难实现。使用简单的算法和简单的数据结构。
Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.
规则 5:数据占主导地位。如果您选择了正确的数据结构并很好地组织了事物,那么算法几乎总是不言而喻的。编程的核心是数据结构,而不是算法。
👍21❤4
#开源项目
一个能够把pdf修改成“扫描”效果的 工具(github地址:https://github.com/rwv/lookscanned.io ),虽然我也不知道把pdf做成扫描效果有什么用。
(补充信息:修改之后,文件大小会明显变大,比如我这个例子中,文件大小会从700KB增大到4MB,另外修改后的文件也不支持选中文字了。)
(附图是把我的数分笔记修改之后的效果。)
一个能够把pdf修改成“扫描”效果的 工具(github地址:https://github.com/rwv/lookscanned.io ),虽然我也不知道把pdf做成扫描效果有什么用。
(补充信息:修改之后,文件大小会明显变大,比如我这个例子中,文件大小会从700KB增大到4MB,另外修改后的文件也不支持选中文字了。)
(附图是把我的数分笔记修改之后的效果。)
👍9
#文章
昨晚阿里云发生大面积故障,今早以前在阿里工作多年的相关人士就写了一篇文章谈系统稳定性,列举了稳定性涉及到的一些思考:《稳定性,难的不是技术,而是》。
大体就是常说的那些:测试边界、降级、减少依赖、灰度。
我非常同意最后的总结:稳定性工作很难出成果,很难被认可,也很难评估投入产出比。这有点像扁鹊三兄弟的故事:能够防病患的老大,才是医术最好的那个,但却又最不为人所知。
昨晚阿里云发生大面积故障,今早以前在阿里工作多年的相关人士就写了一篇文章谈系统稳定性,列举了稳定性涉及到的一些思考:《稳定性,难的不是技术,而是》。
大体就是常说的那些:测试边界、降级、减少依赖、灰度。
我非常同意最后的总结:稳定性工作很难出成果,很难被认可,也很难评估投入产出比。这有点像扁鹊三兄弟的故事:能够防病患的老大,才是医术最好的那个,但却又最不为人所知。
Weixin Official Accounts Platform
稳定性,难的不是技术,而是
作为一个惹出过和处理过一些严重故障的人,我仍然觉得要做好稳定性,最难的并不是技术,或者更准确的说,技术上在怎么做好稳定性,从代码到设计到变更,都有全面的指导思想和原则,但这些思想和原则要落地好,是很复杂的话题。
❤8👍2