
如何持续做一件事?
能持续做下去的事情,往往对自己有不同的意义。
找到做一件事的意义之前,可以思考一下,10年后,自己想成为什么样的人?
可以再细化一下:
- 我想成为什么样的人?
- 成为那样的人需要什么条件?
- 我现在做的这件事情是否满足这些条件?
当一个人能想清楚这些问题时,他就会变得乐观,有毅力勇气、自信、耐心,积极主动…
于是,在整个过程中,他都是高兴的、欢喜的,自然就能长期持续地把这件事做下去。
From:生财有术-明白

能持续做下去的事情,往往对自己有不同的意义。
找到做一件事的意义之前,可以思考一下,10年后,自己想成为什么样的人?
可以再细化一下:
当一个人能想清楚这些问题时,他就会变得乐观,有毅力勇气、自信、耐心,积极主动…
于是,在整个过程中,他都是高兴的、欢喜的,自然就能长期持续地把这件事做下去。
From:生财有术-明白
最近测试环境随便拉了个MySQL最新版的容器,同事发现时区不对,当初也没挂载配置文件,只把数据目录挂出来了,所以时区问题临时解决下得了,反正是测试环境,那么先说下执行的SQL指令吧:
> set global time_zone = '+8:00'; ##修改mysql全局时[......]
进步永远来自于探索,探索是要付出代价的,但是收益更大。对我而言,不敢冒险才是最大的冒险,不敢犯错才是最大的错误,害怕失去会让你失去的更多……
From:左耳朵耗子–我做系统架构的一些原则
最近博客迁移到新的服务器,WordPress后台自检说AMP页面没有设置header的缓存有效期,遂决定人工修改下主题的header,代码如下:
//发送Last-Modified头标,设置文档的最后的更新日期。
header ("Last-Modified: &quo[......]
如果有一天你在做技术决定的时候,开始凭自己以往的经验,那么你就已经不可能再成长了。
人都是不可能通过不断重复过去而进步的,人的进步从来都是通过学习自己不知道的东西。所以,千万不要依赖于自己的经验做决定。
做任何决定之前,最好花上一点时间,上网查一下相关的资料,技术博客,文章,论文等 ,同时,也看看各个公司,或是各个开源软件他们是怎么做的?然后,比较多种方案的 Pros/Cons,最终形成自己的决定,这样,才可能做出一个更好的决定。
From:左耳朵耗子–我做系统架构的一些原则
最近迁移服务器,dump数据库的时候发现个报错:
mysqldump: Got error: 1556: You can't use locks with log tables when using LOCK TABLES查了下是因为dump mysql库的时候,里面是有两个表锁[……]

比如大佬并没有那么认可你,那就坚决不要拉他们到各种群里给自己背书,即使他们到了群里也不会说话,反而降低了信任度;
比如“生财有术”龙珠俱乐部,每个月会定期移除在群里不参与、不分享、不贡献价值的人;
比如及时淘汰不参与线上会议、不执行任务的人,拉黑报名但后续无任何动作、不反馈的人,放弃多次发消息不回应的人。
任何投入都要有预期回报,但是如果对方不重视你的投入,那就等于零回报,应该及时止损。
对那些不重视你的人给出负面回应,把时间精力投入那些重视你的人身上,才是对重视你的人的最大回报。
From:生财有术-亦仁
Docker已经stoped的容器,数量其实一般不会很多,但编译测试的时候,经常会因为脚本种的指令异常、网络问题等等其他未预料的情况造成build终止,从而遗留不少失败时stoped的容器,那么此类容器如何批量清理呢?
依然是一条指令:
printf y|docker cont[......]
如果你已经有了一个事业(或工作),不要冒然扩展到第二个事业(或工作)。因为在初始阶段,增加的引擎会给你带来更多的风险。只有降低单引擎的故障率,并确保你只靠剩下的引擎也能安全降落,双引擎才会给你带来更高的安全性。
不幸的是,就像战争经常推动高风险的飞机设计,人们也通常会在经济困难的时候从事两份工作。如果第一份工作是高负荷的,你再去从事第二份工作,那么很可能到头来,你连第一份工作也保不住。如果那时第二份工作不足以让你维持生计,你就有麻烦了。
不过,计算机时代使得情况有一点点变化。数字控制技术的进步,促成了多轴飞行器的诞生。它们都至少有四个微型引擎,每个引擎只负责总负载的一小部分。任何一个或两个失败,都很容易被其他人弥补。
同样的,在计算机和互联网出现之前,一个人几乎不可能有4个收入来源,但今天,一个人可以有多种小金额的收入来源,比如下班后开网约车、将住宅的空房间作为民宿出租等等。即使每个收入来源都不多,可能也比只有一个主要的收入来源更好、更安全。这里的关键是每个收入来源要尽可能独立,不要相互干扰。
From:阮一峰 科技爱好者周刊(第 189 期) – 为什么双引擎飞机更容易发生事故
有的时候,build镜像会造成很多none的垃圾镜像,通常发布后就可以清理掉了,但编译测试的时候,经常会因为脚本种的指令异常、网络问题等等其他未预料的情况造成build终止,从而遗留一些none的镜像,那么如何批量清理这些none的image镜像呢?一条指令即可:
docker rm[......]