看书和写书,简单而复杂的反思-读书分享会感悟
今天应腾讯云的邀请下参加了新年首期读书分享会,还是很有感触的。对于书目的推荐,本来是要分享一到两本书籍,自己思来想去,自己吐槽自己的书顺手一些,而且可以换个角度来解读一些写书的过程和心路历程,说不上对大家有一定的帮助和借鉴。
我们开始吧。
我的分享分为如下的4个部分,因为分享时间在15分钟左右,所以总体的内容就直白简单一些。我的解读会尽可能聚焦在一本书的过程上,希望通过短短的分享能让大家更聚焦一些,当然在后面我也会推荐一些自己感兴趣的书。
首先是2020年的读书总结,自己看了下各个渠道的数据,总体来说数字成绩不是很理想。今年买了很多的书,书架放不下,在书桌,沙发又开辟了新的战场。我个人对读书的要求会比较偏颇,一般精读得书都会写一些书评,做一些整理。今年最难懂的书是《心经》,是在疫情期间花了两天时间读的,有很多道理似懂非懂,于是我干脆先背了下来,偶尔还会想起来,到现在还有很多点没有搞明白,这算是一段心路的苦旅。而读得最认真的书主要是两本《唐诗三百首》和《凤凰项目》,《唐诗三百首》本来是辅导孩子的,结果自己被吸引了,看得很认真,第二本是《凤凰项目》,整体读了不下两边,每次读都有不同的收获,按照读小说的节奏可以,按照Devops的脉络去读也很有帮助。
而最颠覆认知的书是《穷爸爸富爸爸》,说实话我是穷爸爸的典型心理状态,虽然很打脸但是我很喜欢。
总体来说,读书真是一件性价比很高的事情,能够通过读书改变一个人的思维模型,通过吸星大法提取中书中的精华,这是一种思想上的快捷进取方式。
当然今天的很多老师分享了自己推荐的图书,我这里的观点会有点土,那就是聚焦国内的原创图书市场,其实空间依然很大,栾大成先生观点直白深刻,也是国内原创类图书的巨大挑战,当然这些方面能看到都在不断的改进。
有很多朋友会问我,写技术原创类书籍赚钱吗?问的很直白,但是我的回答不是“是”或者“否”,首先技术原创类书籍的比例整体不是很高,和市面上的畅销书的定义也截然不同,技术图书的畅销是一种细水长流的状态,销量不会井喷,如果能够达到15000本左右,基本上要重印5次以上,主观上就可以归类为畅销书了。
如果让我来自己定义原创技术类书籍的必备条件,我觉得需要考虑如下的一些方面:
首先得有一些技术情结,这种技术情结难以言传,简而言之,就是想做一些添砖加瓦的事情,出发点很单纯。
其次得有相应的素材,这些素材来自于生活和工作,是散乱不成体系的,整合成为体系化的知识结构,这个工作量很大
此外从收益角度,主要有版权问题,也就是你写成的书如果马上被盗版复印,其实内心还是很失落的,销量问题,这些事作者无法控制的事情,可以看到的是网购图书早已成为主流的模式,而我们已经步入了存量时代,在内容的重塑方面,做技术的人会有一种技术洁癖,那就是看自己1年前些的代码或者文章,简直不堪入目,而改进的策略很可能需要重新写,这个代价很高。
最后是迭代编辑,也就是书的内容需要从读者的角度来考虑,哪些地方会有阅读的断层,哪些地方需要更清晰一些。对我来说,三大挑战是:1)把一本书从500页扩展为600页,2)把800页的书删减到600页左右,3)内容的审核方面,我自己会主动推进3到6轮的审核。
写书的缘起,其实是一件很简单的事情。我最大的感触就是记忆打卡,如果处理了一个问题,那么我希望把这个问题的完整过程复现出来,这样下来处理的时候我可以完全按照博客的内容能够快速解答,我是尽量这样做的,所以在这方面是利己到利人的过程。同时这个总结的过程也是在工作中学习,在学习中工作的双向互动阶段。此外,我觉得焦虑是一个人很自然的状态,来自于技术焦虑和生活焦虑,所以这也算是一种表达方式。
从两本书的写作时间来看,其实时间周期比较长,心力耗费比较高,如果说写博客是一种爬格子生活,那么写书的素材就是这些平淡的细节,而能够整合成知识体系就是另外一件事情了。这个过程的工作量超过了我自己的想象,相信写过书的人都会感觉自己比读者的收获更大,无外于此。
当然有了弹药,有了激情,还能够持续投入,那么还有很多其他的因素需要考虑,在这方面,值得一提的是,自己也曾经策划过另外一本书,都投入了40%的精力,最后还是无奈放弃了。
会到这本书设计的初衷,一般行业里通常看到的MySQL书是面向数据库管理的内容会多一些,而对于架构优化和运维开发的部分难以成为体系,这方面的内容是相对比较匮乏的。架构设计的难点在于很多内容是经验的沉淀,有些深度的内容篇幅过长,难以表达清楚,而且对于架构,如果说有数据库架构的共识,那么实现的方式是很难达成共识的。所以这些内容在网络上也是相对比较零散的。最后是运维开发,在运维体系中,一般都是自下而上的构建过程,相对来说,如果规划一个运维开发体系,能够让有些工作能够落地,这是一个大问题,也是一个尴尬的问题,我是从零开始学习Python,从零构建基于Python的运维开发体系,在细节上做得不尽如人意,但是至少这个技术堡垒被构建出来了,我希望呈现的也是这种设计思想和思维,而换个角度来看,现在看很多思想还是不够深入,还需要继续深入演化。
我不太喜欢那种说自己的书怎么好,我提几个特色吧。首先是这本书的最大感受,这是编辑老师问我的一个问题,我当时的一句话总结就是“技能进阶推动思维转型”,这也是我自己的目前的技术理想。整个笔记算是基本真实还原了DBA生活的缩影,另外我想表达的是需要换个视角,不要单纯从MySQL的角度去看待问题,应该还有很合适的方案,最后是我的个人最爱,那就是章前引导语,我摘录了一些个人喜欢的语录和座右铭,放在每章的开头。
至于缺点,我觉得可以说得直白一些,至少自我批评也得深刻。
首先是一些低级错误,比如空格,拼写错误,这些不尽如人意的地方依然存在。
再次是内容的篇幅过大,整本书600页出头,势必会在内容深度上打折,在这方面,也是自我感觉会有些遗憾的地方。
第三是技术更新度上,很多技术书都有这个硬伤,一些技术经过2年的迭代就会成为非主流,就需要持续演进,目前的书的内容还是以5.7为主,这是需要进一步改进的方向。
最大的痛点其实就是把书写薄,能够沉淀成为一些方法论,深度的感悟,能够让技术更新度和技术思想松耦合,在技术专题方向要深耕,这是我个人比较强烈转变的地方。
说几点看书的心得吧,我个人是比较喜欢在一本书的扉页写下看书的日期,然后过一段时间回头再看的时候,通常会发现已经过去了半年一年以上,这种时间上的跨度带给我的是一些新的体验和惊喜。
另外看一本书有个要点,就是大纲目录和前言是我们需要着重关注的,有些语言风格和内容是不是和自己的期望匹配,这些地方就能够基本看出来。
最后是总结,好记性不如烂笔头,要把书读薄,就要吸取其中的精华,而这些提炼精华就是我们需要自己完成的工作。
最后推荐几本书吧,主要分为非技术和技术两大类,个人重点推荐《禅与摩托车维修艺术》这本书我读了2年,还没有读完,我觉得阅读的那种体验非常棒,
第二本是《凤凰项目》,可以按照非技术类来读,也可以从Devops的视角进行解读,各有收获,我觉得可以总结的一点就是,书里面的故事有很多细节是值得思考的,哪些过程是不可复制的,哪些条件从量变达到了质变,这是我经常在思考的问题。
最后是软件学报,这是我强烈推荐的期刊,作为顶级期刊,里面的很多内容开阔了我的眼界,我个人比较喜欢这种深度的信息,而且也推荐大家多看看一手的信息源数据。
最后也祝大家能够学有所成。
此外,有些网友提出了一些问题,我简单做了回答:
1、老师,修炼dba基本功看那些书籍比较好啊
A: 我个人总结了一个链接,可以参考这个回答,针对新人和进阶有不同的推荐。
2、老师,作为一名作者,您认为应该如何快读,怎么让自己快速去了解一本书呢?
A:如果快速去了解一本书,我推荐使用音频/视频解读的模式,这种方式能够快速了解一本书的内容
好书其实推荐是精读模式,这种方式可以参考一些读书笔记和书评,个人比较喜欢豆瓣,论坛的点评,
另外一方面,我是推荐参加这种读书会,在质量方面有保证。
3、mysql dba在工作中,有哪些好的工具软件推荐?
A:运维管理类工具:侧重于DBA使用的工具,包含备份恢复、审计等工具;如Percona-toolkit,Xtrabackup
监控管理类工具:主要是侧重于系统层和数据库层的监控管理,也包含一些开源方案,如Lepus,Zabbix,Prometheus
应用工具:主要包含客户端工具;强烈推荐Workbench
诊断和优化工具:侧重于性能诊断和优化,包含性能诊断、慢日志分析和性能测试工具;如Innotop,sysbench,Percona-toolkit
4、请问老师 mysql读写分离中间件 总结或推荐吗?
A: 读写分离的特性,其实选择很多,比如MyCAT,Sharding-sphere,ProxySQL
5、老师在数据库运维管理上,可以用bash程序来完成python语言来完成的任务吗?
A:我觉得可以以终为始,用结果来衡量过程,Shell有自己的优势,也有自己的缺点,换一种角度,Python也是如此,从功能开发和个人成长方面,还是建议至少掌握一门高级语言。