微信阅读两周记(r11笔记第77天)

   最近读了一些书,几乎都是在地铁上,下班路上读的,差不多两个星期的时间里,阅读时间就达到了近30个小时,所以你说没时间没时间,时间就在这里。  

   那么谱儿已经摆出来了,到底读了些什么书呢,这个还得好好唠唠。

   我电子书架上的书有多少,大概屯了45本,自己买的是绝少数,两周内花钱买了不到5本,还有相当多是试读,还有朋友送的,互赠的。做书评,笔记的书有24本,也就意味着我读了这些书,可能大部分还在进行中,还没有读完。

    读了哪些方面的书,我来简单盘点下。主要都是人文类的为主,这些天主要读了两本较厚的书。一本是《创业小败局》,也是无意看到海朝在看这本书,就好奇看了下,一下子被吸引住了。

  我想这也是互联网阅读的一个很大的好处,就是你都完全不用开口去问,就会得到很多你想得到的信息。

  
我可以想象很多创业的企业都是命悬一线,创业者在时刻面临资金链断裂的边界线上挣扎,有统计显示,中国企业能活过3年的不超过10%,所以说创业也是一个高危行业。里面的故事需要好好消化,有时候我感觉我就是里面的主人公,在身临其境的状态下看,注意力就会尤其集中。没准哪天我还真会走上这条路。

  第二本是马伯庸的一本小说,看了封面的一小段话,就被吸引住了,我以为这是一部正史或者纪实小说,但是打开之后发现是一个虚拟的故事,但是里面的很多学问是有考据的。

   这样一本书,洋洋洒洒极端故事下来,我觉得书中留下了很多伏笔,前后呼应尤其重要。当然我也发现了一些细小的错误,不过瑕不掩瑜。总体来说,写得很不错,至少我会带着点疑问和好奇想继续看下去,直到读完。

    剩下的书基本都是知乎一小时系列。篇幅相对就会少很多。但是读得要快一些。大概有4本左右。

   
通过这段时间的体验,我有一个很深的体验就是心里还是拧不过这个劲儿来,比如读电子书花了10块钱可能心里就有些舍不得,但是如果纸质的书,10块钱肯定拿不下来,心里就会给自己一个暗示,下载盗版的,但是每每这样想,就同时被自己批判的败下阵来。我认真读完两本书,都是付费购买的,我发现自己会尤其花心思去看。而如果一本大部头的书免费给你,可能还会容易被冷落。所以书非解不能读也,同时也是书非买不能读也。

   如果你自己心里给自己算笔账,你会觉得当前的顽固思维还是蛮可笑的,吃饭的时候我压根不会在意贵个几块,十多块钱,平时也经常骑骑摩拜单车,都已经充了不少钱了。读书的地方有时候还是想不通,所以这个梗得解,而且只能自己解。

  读书是个需要坚持的事情,我能够感受到身边的很多朋友已经懈怠了,我想会在放弃-重新拾起-放弃这样的循环中反反复复。

读书是自己的事情,自己的事情自己来把握吧,就如同把握自己的未来一样,路都要自己来走,没有任何捷径可走。

   

  

时间: 2024-09-21 15:14:21

微信阅读两周记(r11笔记第77天)的相关文章

我看好互联网阅读(r11笔记第63天)

    微信近几年进入了大家的视野,然后发展势头一发不可收拾,现如今已经形成了一个庞大的生态,当初看好还是看低,现如今已经经受了时间的考验,站稳了脚跟.举一个最简单的例子,今年过年拜年,除了个别亲戚朋友电话拜年外,剩下用短信拜年的我估计都是个位数吧,我个人今年只收到了一条拜年短信,剩下近千条都是微信中接收的.而前些年还在双线拜年.    而对于传统的阅读来说,是不是也能跟上互联网的大风呢.电子书本身不是个新鲜玩意,kindle,手机客户端都有读书软件,这个和互联网阅读有什么关系,我说的不一定对,

insert导致的性能问题大排查(r11笔记第26天)

今天开发的同学小窗口消息给我,向我咨询一个ORA错误的问题. 错误代码是ORA-30036,使用oerr ora 30036查看,由于是undo空间无法扩展导致. 这是一个统计业务的数据库,而且平时的负载其实并不高,确实有一些奇怪.首先排除了大事务导致的原因,查看数据库日志,和开发同学沟通,没有发现相关的错误信息. 所以第一感觉这是一个偶然发生的情况,不过开发的这位同学貌似碰到了问题,他说从应用端抛出了ORA-30036的错误. java.sql.BatchUpdateException:ORA

微信阅读量正在成为最被微信订阅号们关注的话题

微信阅读量正在成为最被微信订阅号们关注的话题,其背后则隐藏着庞大的黑色产业链条. 在微信对公众平台图文消息修改规则后,"万能的淘宝"迅速跟进,一时间出现大量网店提供刷阅读量.点赞的服务.随后腾讯表示开始打击造假的技术手段,包括使用校验码等,后台会对一个账号.或同一个设备号.同一个用户重复访问等疑似作弊情况从阅读数中删除,并将推出一段时间的封号警告和永久性封号等惩罚措施.随即大部分淘宝上的微信刷阅读量商品开始下线,看起来一切回归正轨. 但这些还远远不够,据网易科技了解,淘宝上的微信刷阅读

MySQL Online DDL(二)(r11笔记第88天)

对于Online DDL,之前简单分析了一些场景MySQL中的Online DDL(第一篇)(r11笔记第3天),其实有一个很关键的点没提到,那就是online DDL的算法,目前有三个操作选项,default,inplace,copy可选 具体可以参考  https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.html > select count(*) from newtest; +----------+ | count(*) |

需要了解的pssh(r11笔记第28天)

   昨天的一篇文章,关于ssh命令的几个使用小技巧(r11笔记第27天),也收到了不少朋友的反馈,其中有个朋友提议说还是用pssh吧,我想想也是.     对于pssh早有耳闻,但是一直没有尝试用过.自己体验了一番,感觉确实不错,对于我们日常碰到的批量操作都可以胜任.当然还有很多可选方式,比如pgm,fabric,puppet,ansible等,只要能实现需求,怎么玩都是套路,而且也急不得,一个学明白了学其他的就会容易很多.      关于pssh的p是什么含义,我和朋友还讨论过,到底是pyt

近期的学习计划(2017.3)(r11笔记第95天)

    发现我已经开始不按照时间管理软件的进度来跟踪工作了,工作学习都是如此,这样就会和计划脱钩,简单来说,很可能会有瞎忙活的情况,还是得来总结下近期的学习计划.计划就得落地,就得实打实的来做,我有信心完成.    接下来的时间,我会给自己留的尽量短一些,这样能够短期看到成效. MySQL方向 没错,短期内我的重心会放在MySQL上,里面有许多需要借鉴学习和深入学习的地方.   MySQL和Oracle的优化     可以参考 <高性能MySQL>,感觉里面提出的一些点还有待完善,我会逐步总结

复杂SQL性能优化的剖析(二)(r11笔记第37天)

    昨天的一篇文章复杂SQL性能优化的剖析(一)(r11笔记第36天) 分析了一个SQL语句导致的性能问题,问题也算暂时告一段落,因为这个语句的执行频率是10分钟左右,所以优化后(大概是2秒左右,需要下周再次确认)的提升很大.    对于优化是一个持续的改进,我们碰到的问题,最终的原因可能五花八门,但是正如柯南所说,真相只有一个.我把这个问题和前几天处理的一个问题结合起来,前几天处理了一个紧急问题,也是有一个SQL语句的执行计划发生改变,这个语句的业务比较关键,触发频率是每分钟一次,如果一旦

百倍性能的PL/SQL优化案例(r11笔记第13天)

我相信你是被百倍性能的字样吸引了,不过我所想侧重的是优化的思路,这个比优化技巧更重要,而结果嘛,其实我不希望说成是百倍提升,""自黑""一下.     有一个真实想法和大家讨论一下,就是一个SQL语句如果原本运行20秒,优化到了1秒,性能提升该说是20倍还是提高了95%.当然还见过一种说法,一条SQL语句每次运行20秒,每天运行100次,优化后每次运行1秒,运行还是100次,那么性能提升是说成优化累计时间为100*20-100=1990秒? 好了,我们来看看PL/S

闪回原理测试(二)(r11笔记第23天)

    对于闪回部分,Oracle本身提供了非常多相关的特性,我个人对于闪回数据库这个特性最为喜爱,尤其是应用再Data Guard环境中,真是一大杀器.     而对于DML的闪回部分其实也相对比较容易理解,毕竟就是原操作的逆操作,之前通过logminer的方式来读取redo来间接得以印证.Oracle闪回原理-Logminer解读redo(r11笔记第17天)     但是对于DDL的闪回,这个特性真是非常强悍了.比如一个truncate操作,它的逆操作改怎么定义,就很难去界定了.当然这个里