乌兰察布之旅

上个周末,我和朋友们一起去了内蒙的乌兰察布,这个地方以其壮丽的草原和火山而闻名。我们的第一天是去了乌兰哈达火山群 🌋,那里有四五座,现在都已经不再喷发了。到达后我们一行人选择了其中的两座进行探索 🌍,广袤无垠的草原和那些突兀的火山给我们带来了非常棒的感受。在观赏完火山景色后,天色渐暗,我拿出相机拍摄了日落延时摄影 🌄,整个过程中我拍摄了六百多张照片,最后将它们合成了一个十秒的视频,尽管画面的色调有些暗淡,但整体效果还是相当不错的。

第二天我们去的“黄花沟”,那里是片不错的草原,草、花和风车交相辉映,我们用相机记录下片刻的时光。

整个旅程中除了在路上花费了一些时间外,整体的体验还是相当不错的。如果你让我推荐是否值得从北京去乌兰察布,我会持推荐态度,时间安排三天是比较合适的选择。

编程|做合适的系统设计

我一直觉得编程就像走迷宫,当我们把程序功能都跑起来,说明前人已经把这些路都探索走过了;当我们把一个功能开发测试完毕发布,就像从乌漆麻黑的草丛里穿过,最终看到光明;当程序出现一些问题,我们根据自己的经验排查链路、debug 代码仿佛又一头扎进伸手不见五指的迷雾。

归根到底,这些是系统设计和编码规范的问题。系统设计是难的,需要不断权衡,同时可能会让人陷入邪恶的设计循环,导致复杂的设计;编写代码的人不同,导致代码不易理解;另一个很重要的因素是时间,时间会让人遗忘,并且人对代码的认知会随着时间的推移改变。

摄影一二三

《影像》

用眼睛发现,
那些美好值得记录的。
用相机捕获,
转瞬既逝的光影。
用时间陈酿,
此时此刻的记忆。

摘|具有适应性的复杂系统

当我们说一个组织是一个具有适应性的复杂系统时,我们指的是:

  • 它包含许多相互依赖的部分(比如人员、技术、流程、文化等)。
  • 各个部分可以自行改变自己的行为,并适应系统的变化。

宇宙中充满了这类的系统,而且关于复杂性的研究已成为一门成熟的科学学科。 就连你自己也是一个具有适应性的复杂系统。你可能认为自己是一个单元(即一个自我),但是“自我”只是一种抽象。实际上,你是有机细胞的集合,尽管这个细胞集合拥有许多惊人的能力:思考、移动、感知,并作为一个全新的整体对外部做出反应。从细胞的角度来说,你的每个细胞都有专门的作用,细胞会进行新陈代谢,细胞群通过协同工作对你的身体产生巨大的影响。你体内生物系统的复杂性使得你的身体具有高度的弹性和适应性。虽然你不能长生不老,但由于体内复杂的生物系统,你仍然可以承受巨大的环境变化,甚至是人身伤害。

Java|进度条工具

有时候批量处理任务无法观察执行情况,例如处理进度、处理数量、耗时等,这种“不确定性”会隐藏 bug,等到出问题就晚了。今天,这篇文章的“主角” —— 进度条工具 —— 就是为了解决这个问题。

进度条工具输出预览:

 1[4B645A43] 远程请求记录: [####                ] - 22.91% (9835/42920), 耗时: 2m32s
 2   (1)        (2)               (3)               (4)       (5)          (6)
 3
 4各部分说明:
 5
 6(1) Trace ID
 7(2) 进度条名称
 8(3) 进度条面板
 9(4) 执行占比
10(5) 执行数量细节
11(6) 执行耗时

春暖花开好时节

视频,阅读全文查看。

技术之外重要的

今晚讨论了一些技术之外对人成长有帮助的,我觉得有一些意义。

在大学中,老师教的往往都是技术,学生们学习技术以期望未来找个理性的工作。首先可以肯定技术是重要的,它是“饭碗”,为人提供了物质基础,但人在学习技术之外还有其他重要的需要学习了解(如下),这些不会直接提高技术能力,但能让人生活的更好。

  • 学习表达
    • 表达感性;
    • 表达态度,肯定、支持、接受、拒绝;
    • 表达爱憎。
  • 学习去爱
  • 学习生活
  • 学习打理着装
  • 培养兴趣
  • 培养耐心、专注(聚焦)

这里的观点是,太专注技术和理论会让人趋于理性,就像一台冰冷的机器,因此人需要学习了解技术之外事物让人格更加丰富、鲜活,成为一个独特的个体,有温度的人。

读《Google 软件工程》

image

Software Engineering at Google》。

这本书从三个角度说明了软件工程是什么,分别是:时间、规模、权衡。时间应该是软件工程中最大的变量,随着时间推移新需求会出现,框架和库会升级打补丁,而原先的产品设计、服务端的算法、机器资源可能已经不再适合,这些变化需要维护,如何应对解决这些问题呢?当产品及业务扩大时,对应资源开销也会逐渐增大,资源包括人力和硬件资源(内存、CPU、存储、带宽),当这些规模不断增大如何保障相应的效率、成本?当面临这些问题时,往往不止一个方案,没有银弹,我们需要权衡利弊然后再再行动。在软件开发中会遇到许多诸如以上的问题,从这个角度可以窥探软件工程一些细节。

优化一下SQL,性能提升20倍

最近在大数据平写 Hive SQL 跑离线作业,数据量大概在三千万,有一个离线任务每次执行都要两个小时以上,我感觉太慢了。为什么觉得慢?刨除实现 SQL 逻辑的时间,自测、冒烟测试、上线每次执行一次需要 2h,也就是修改一处 SQL 要经历 6 小时才能看到最终结果。根据我的经验判断不应该耗费这么长时间,于是想着看看能不能改善一下。我先让数据平台的同学帮忙看,由于他们忙没得到结果,于是自己动手优化了一下,优化后的结果还是比较让我吃惊的,因为我并没有使用很复杂高深的手段(主要是减少临时表、减少嵌套查询数),却得到了意向不到的效果。这使我产生许多想法和思考。

优化效果,时间减少 95%,内存减少 80%。

  • 优化前:耗时 2h,内存占用 80G
  • 优化后:耗时 6min,内存占用 16G

Leader and Programer

If you used to be a programmer, your life was likely calmer and more panicfree. You had a list of work to do, and each day you’d methodically work down your list, writing code and debugging problems. Prioritizing, planning, and executing your work was straightforward.

如果你曾经是个程序员,你的生活很可能要比现在平静,没有很多让人恐慌的状况需要处理。你有完整的工作清单,上面的每个条目你都能有条不紊的解决,写代码或是调试问题。排优先级、定计划,然后执行你的工作,还是很简单的。

As you moved into leadership, though, you might have noticed that your main mode of work became less predictable and more about firefighting. That is, your job became less proactive and more reactive. The higher up in leadership you go, the more escalations you receive. You are the “finally” clause in a long list of code blocks!

当你在管理岗工作后,你可能慢慢察觉到了,你的工作模式变得不可预测,天天都在救火。你的工作变得被动,更多的是响应别人的诉求。你的岗位越高,这个现象越明显。你成了一堆代号的最终负责人。

Individual contributor as a tiny gear with just a few teeth all the way at one end, and each successive manager above them as another gear, ending with the CEO as the largest gear with many hundreds of teeth. This means that every time that individual’s “manager gear” (with maybe a few dozen teeth) makes a single revolution, the “individual’s gear” makes two or three revolutions. And the CEO can make a small movement and send the hapless employee, at the end of a chain of six or seven gears, spinning wildly!

个人是一个很小的齿轮,只有几个齿,而他们之上的每个继任经理都是另一个齿轮,最后 CEO 是有数百颗牙的最大齿轮。这意味着个人的 “经理齿轮”(可能有几十个齿)每转一圈,“个人的齿轮 “就转两三圈。而首席执行官可以做一个小动作,让处于六、七个齿轮链末端的无助的员工疯狂地旋转!

(via)