观点 32


科学讲因果,社会讲责任。


活好

How many heartcounts do I have?


每个人都不一样,和而不同。


其实HTTP协议背后的设计理念,可以认为是在说一个人,挺有意思的。


正弦 (1)

所有完美的背后,都是残缺; 所有成功的背后,都是苦难; 所有得到的背后,都是失去


现有的大部分商业、免费的绘图工具的基本假设是,图片的作者与图片的使用者,使用的是同一个工具,并没有考虑到图片的具体引用场景,并根据上下文环境进行自适应调整。


RESTful 是一个将HTTP传输协议以及JSON报文体相结合的RPC通信风格,但目前并不存在一个得到普遍认可和约束的工业技术规范。由于RESTful风格形式简洁,工具链丰富,收到广大开发者的喜爱。同时也由于其落地实现的随意性,导致各大企业都有不同的落地实现方法,形成了不同形态的「方言」。无形之中增加了软件互联的成本,造成了有限的研发资源浪费。EnhancedREST规范了不同系统之间的技术标准,降低产品间的集成成本,提高研发效率。


从软件产品的生产关系,看软件是如何被制造出来的。程序员们为什么要加班?


REST还是太过于简单,缺乏在众多复杂分布式应用场景下直接应用的能力。本文通过对HTTP/1.1协议的深入挖掘,设计一套设计REST-like的RPC通信协议。


REST还是太过于简单,缺乏在众多复杂分布式应用场景下直接应用的能力。本文对REST的不足进行了分析,对复杂场景下的RPC协议与报文的要求进行了梳理。


PaaS就像踩在海洋球上的空中楼阁.


软件源代码、学术论文和发明专利,都是专业知识工作的成果。它们的获得方法、价值的体现方式,都有着很多的相似之处。机器学习,让计算机从专业知识的价值放大器变为了开发器。


理解软件

软件本质上是复杂的。但,软件表象上「应该」是简单的。


从大局上,正确定义和理解软件结构上的基本概念,是深入理解软件,提升团队生产力和创造力的基础。


软件,不简单

人们偏爱「娱乐化的图形、语音和视频」,计算机偏爱「严肃的数据和逻辑」。


标识是无处不在的,生成标识的主体是人,那么它就是一个命名过程,如果是计算机,那么它就是一个生成过程。如何保证分布式系统下,并行生成标识的唯一与标识的命名空间有着密不可分的关系。


2016年8月22日 发表于 InfoQ · 聊聊架构 「撇开代码不说,谈谈我对架构的6个冷思考」


API/SPI 的调用,有很大的一部分比例,都是为了做数据同步,很多场景这种用法是错误的。


平台运营首先需要帮助每个用户弥补短板,鼓励每个平台的参与者向平台贡献内容并得到广泛的认可、体现他们的价值,从而重点激发平台上的每个用户的自身潜力,同时也需要严格监管平台上的不良用户,保障一个健康、有序的生态环境。


其实从敏捷延展开的 DevOps 概念很早就已经被提出,不过由于配套的技术成熟度水平层次不齐, DevOps 的价值需一直没有有效的发挥出来。现如今随着容器技术的发展, DevOps 在企业中的实践难度大幅降低,其价值也得以体现。


数字化是近期全球的热点,数字化与很多其他概念例如:「信息化」、「自动化」似曾相识。在追逐数字化这个概念之前,需要深入分析数字化的本质,以便找到数字化的正确应用路径。


面向操作型(交易型)和面向概念型(主数据型)的两类唯一性标识生成策略。


IETF 从1996年至今,关于HTTP协议的定义超过17个,涵盖HTTP 1.0/1.1/2 。基于HTTP的RESTFul风格,是对HTTP协议的一次功能挖掘。


生成不依赖运行环境、人可读、方便输入的全局唯一的标识是有多难。


不要抱怨变化,变化是人的认知、社会进步的结果。


对于信息技术的使用,都是意识决定形态,形态反作用意识的结果。只有电子游戏没有康威定律什么事。


架构师就是为了解决一个问题,发现这个问题背后的十个问题,最后发现世界全是问题。


煮汤圆不算是个很复杂的技术活,为什么没有煮汤圆机以及智能煮汤圆机这个产品出现呢?