From be4c50e2c7eb8cd25864061c12154fafc401c7d2 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Sat, 2 Dec 2017 23:35:45 +0800 Subject: [PATCH 01/16] translated by yunfengHe --- ...20 Containers and Kubernetes Whats next.md | 38 ++++----- ...20 Containers and Kubernetes Whats next.md | 79 +++++++++++++++++++ 2 files changed, 98 insertions(+), 19 deletions(-) create mode 100644 translated/tech/20171120 Containers and Kubernetes Whats next.md diff --git a/sources/tech/20171120 Containers and Kubernetes Whats next.md b/sources/tech/20171120 Containers and Kubernetes Whats next.md index b73ccb21c2..1a8400d7cd 100644 --- a/sources/tech/20171120 Containers and Kubernetes Whats next.md +++ b/sources/tech/20171120 Containers and Kubernetes Whats next.md @@ -6,16 +6,16 @@ Containers and Kubernetes: What's next? ![CIO_Big Data Decisions_2](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO_Big%20Data%20Decisions_2.png?itok=Y5zMHxf8 "CIO_Big Data Decisions_2") -If you want a basic idea of where containers are headed in the near future, follow the money. There’s a lot of it: 451 Research projects that the overall market for containers will hit roughly [$2.7 billion in 2020][4], a 3.5-fold increase from the $762 million spent on container-related technology in 2016. +If you want a basic idea of where containers are headed in the near future, follow the money. There’s a lot of it: 451 Research projects that the overall market for containers will hit roughly [$2.7 billion in 2020][4], a 3.5-fold increase from the $762 million spent on container-related technology in 2016. -There’s an obvious fundamental factor behind such big numbers: Rapidly increasing containerization. The parallel trend: As container adoption grows, so will container  _orchestration_  adoption. +There’s an obvious fundamental factor behind such big numbers: Rapidly increasing containerization. The parallel trend: As container adoption grows, so will container _orchestration_ adoption. -As recent survey data from  [_The New Stack_][5]  indicates, container adoption is the most significant catalyst of orchestration adoption: 60 percent of respondents who’ve deployed containers broadly in production report they’re also using Kubernetes widely in production. Another 19 percent of respondents with broad container deployments in production were in the initial stages of broad Kubernetes adoption. Meanwhile, just 5 percent of those in the initial phases of deploying containers in production environments were using Kubernetes broadly – but 58 percent said they were preparing to do so. It’s a chicken-and-egg relationship. +As recent survey data from [_The New Stack_][5] indicates, container adoption is the most significant catalyst of orchestration adoption: 60 percent of respondents who’ve deployed containers broadly in production report they’re also using Kubernetes widely in production. Another 19 percent of respondents with broad container deployments in production were in the initial stages of broad Kubernetes adoption. Meanwhile, just 5 percent of those in the initial phases of deploying containers in production environments were using Kubernetes broadly – but 58 percent said they were preparing to do so. It’s a chicken-and-egg relationship. -Most experts agree that an orchestration tool is essential to the scalable [long-term management of containers][6] – and corresponding developments in the marketplace. “The next trends in container orchestration are all focused on broadening adoption,” says Alex Robinson, software engineer at [Cockroach Labs][7]. +Most experts agree that an orchestration tool is essential to the scalable [long-term management of containers][6] – and corresponding developments in the marketplace. “The next trends in container orchestration are all focused on broadening adoption,” says Alex Robinson, software engineer at [Cockroach Labs][7]. -This is a quickly shifting landscape, one that is just starting to realize its future potential. So we checked in with Robinson and other practitioners to get their boots-on-the-ground perspective on what’s next in container orchestration – and for Kubernetes itself. +This is a quickly shifting landscape, one that is just starting to realize its future potential. So we checked in with Robinson and other practitioners to get their boots-on-the-ground perspective on what’s next in container orchestration – and for Kubernetes itself. ### **Container orchestration shifts to mainstream** @@ -25,40 +25,40 @@ We’re at the precipice common to most major technology shifts, where we transi ### **Reduced complexity** -On a related front, expect an intensifying effort to cut back on the complexity that some organizations face when taking their first plunge into container orchestration. As we’ve covered before, deploying a container might be “easy,” but [managing containers long-term ][8]requires more care. +On a related front, expect an intensifying effort to cut back on the complexity that some organizations face when taking their first plunge into container orchestration. As we’ve covered before, deploying a container might be “easy,” but [managing containers long-term ][8]requires more care. -“Today, container orchestration is too complex for many users to take full advantage,” says My Karlsson, developer at [Codemill AB][9]. “New users are often struggling just to get single or small-size container configurations running in isolation, especially when applications are not originally designed for it. There are plenty of opportunities to simplify the orchestration of non-trivial applications and make the technology more accessible.” +“Today, container orchestration is too complex for many users to take full advantage,” says My Karlsson, developer at [Codemill AB][9]. “New users are often struggling just to get single or small-size container configurations running in isolation, especially when applications are not originally designed for it. There are plenty of opportunities to simplify the orchestration of non-trivial applications and make the technology more accessible.” ### **Increasing focus on hybrid cloud and multi-cloud** -As adoption of containers and container orchestration grows, more organizations will scale from a starting point of, say, running non-critical workloads in a single environment to more [complex use cases][10] across multiple environments. For many companies, that will mean managing containerized applications (and particularly containerized microservices) across [hybrid cloud][11] and [multi-cloud][12] environments, often globally. +As adoption of containers and container orchestration grows, more organizations will scale from a starting point of, say, running non-critical workloads in a single environment to more [complex use cases][10] across multiple environments. For many companies, that will mean managing containerized applications (and particularly containerized microservices) across [hybrid cloud][11] and [multi-cloud][12] environments, often globally. -"Containers and Kubernetes have made hybrid cloud and application portability a reality,” says [Brian Gracely][13], director of [Red Hat][14] OpenShift product strategy. “Combined with the Open Service Broker, we expect to see an explosion of new applications that combine private and public cloud resources." +"Containers and Kubernetes have made hybrid cloud and application portability a reality,” says [Brian Gracely][13], director of [Red Hat][14] OpenShift product strategy. “Combined with the Open Service Broker, we expect to see an explosion of new applications that combine private and public cloud resources." -“I believe that federation will get a push, enabling much-wanted features such as seamless multi-region and multi-cloud deployments,” says Carlos Sanchez, senior software engineer at [CloudBees][15].  +“I believe that federation will get a push, enabling much-wanted features such as seamless multi-region and multi-cloud deployments,” says Carlos Sanchez, senior software engineer at [CloudBees][15]. -**[ Want CIO wisdom on hybrid cloud and multi-cloud strategy? See our related resource, **[**Hybrid Cloud: The IT leader's guide**][16]**. ]** +**[ Want CIO wisdom on hybrid cloud and multi-cloud strategy? See our related resource, **[**Hybrid Cloud: The IT leader's guide**][16]**. ]** ### **Continued consolidation of platforms and tools** Technology consolidation is common trend; container orchestration is no exception. -“As containerization goes mainstream, engineers are consolidating on a very small number of technologies to run their [microservices and] containers and Kubernetes will become the dominant container orchestration platform, far outstripping other platforms,” says Ben Newton, analytics lead at [Sumo Logic][17]. “Companies will adopt Kubernetes to drive a cloud-neutral approach as Kubernetes provides a reasonably clear path to reduce dependence on [specific] cloud ecosystems.**”** +“As containerization goes mainstream, engineers are consolidating on a very small number of technologies to run their [microservices and] containers and Kubernetes will become the dominant container orchestration platform, far outstripping other platforms,” says Ben Newton, analytics lead at [Sumo Logic][17]. “Companies will adopt Kubernetes to drive a cloud-neutral approach as Kubernetes provides a reasonably clear path to reduce dependence on [specific] cloud ecosystems.**”** ### **Speaking of Kubernetes, what’s next?** -"Kubernetes is here for the long haul, and the community driving it is doing great job – but there's lots ahead,” says Gadi Naor, CTO and co-founder of [Alcide][18]. Our experts shared several predictions specific to [the increasingly popular Kubernetes platform][19]:  +"Kubernetes is here for the long haul, and the community driving it is doing great job – but there's lots ahead,” says Gadi Naor, CTO and co-founder of [Alcide][18]. Our experts shared several predictions specific to [the increasingly popular Kubernetes platform][19]: - **_Gadi Naor at Alcide:_**  “Operators will continue to evolve and mature, to a point where applications running on Kubernetes will become fully self-managed. Deploying and monitoring microservices on top of Kubernetes with [OpenTracing][20] and service mesh frameworks such as [istio][21] will help shape new possibilities.” + **_Gadi Naor at Alcide:_** “Operators will continue to evolve and mature, to a point where applications running on Kubernetes will become fully self-managed. Deploying and monitoring microservices on top of Kubernetes with [OpenTracing][20] and service mesh frameworks such as [istio][21] will help shape new possibilities.” - **_Brian Gracely at Red Hat:_**  “Kubernetes continues to expand in terms of the types of applications it can support. When you can run traditional applications, cloud-native applications, big data applications, and HPC or GPU-centric applications on the same platform, it unlocks a ton of architectural flexibility.” + **_Brian Gracely at Red Hat:_** “Kubernetes continues to expand in terms of the types of applications it can support. When you can run traditional applications, cloud-native applications, big data applications, and HPC or GPU-centric applications on the same platform, it unlocks a ton of architectural flexibility.” - **_Ben Newton at Sumo Logic: _ “**As Kubernetes becomes more dominant, I would expect to see more normalization of the operational mechanisms – particularly integrations into third-party management and monitoring platforms.” + **_Ben Newton at Sumo Logic: _ “**As Kubernetes becomes more dominant, I would expect to see more normalization of the operational mechanisms – particularly integrations into third-party management and monitoring platforms.” - **_Carlos Sanchez at CloudBees: _** “In the immediate future there is the ability to run without Docker, using other runtimes...to remove any lock-in. [Editor’s note: [CRI-O][22], for example, offers this ability.] “Also, [look for] storage improvements to support enterprise features like data snapshotting and online volume resizing.” + **_Carlos Sanchez at CloudBees: _** “In the immediate future there is the ability to run without Docker, using other runtimes...to remove any lock-in. [Editor’s note: [CRI-O][22], for example, offers this ability.] “Also, [look for] storage improvements to support enterprise features like data snapshotting and online volume resizing.” - **_Alex Robinson at Cockroach Labs: _ “**One of the bigger developments happening in the Kubernetes community right now is the increased focus on managing [stateful applications][23]. Managing state in Kubernetes right now is very difficult if you aren't running in a cloud that offers remote persistent disks, but there's work being done on multiple fronts [both inside Kubernetes and by external vendors] to improve this.” + **_Alex Robinson at Cockroach Labs: _ “**One of the bigger developments happening in the Kubernetes community right now is the increased focus on managing [stateful applications][23]. Managing state in Kubernetes right now is very difficult if you aren't running in a cloud that offers remote persistent disks, but there's work being done on multiple fronts [both inside Kubernetes and by external vendors] to improve this.” -------------------------------------------------------------------------------- @@ -95,4 +95,4 @@ via: https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-w [22]:http://cri-o.io/ [23]:https://opensource.com/article/17/2/stateful-applications [24]:https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next?rate=PBQHhF4zPRHcq2KybE1bQgMkS2bzmNzcW2RXSVItmw8 -[25]:https://enterprisersproject.com/user/kevin-casey +[25]:https://enterprisersproject.com/user/kevin-casey \ No newline at end of file diff --git a/translated/tech/20171120 Containers and Kubernetes Whats next.md b/translated/tech/20171120 Containers and Kubernetes Whats next.md new file mode 100644 index 0000000000..a6e7b8f7e6 --- /dev/null +++ b/translated/tech/20171120 Containers and Kubernetes Whats next.md @@ -0,0 +1,79 @@ +容器技术和 k8s 的下一站： +============================================================ +### 想知道容器编排管理和 K8s 的最新展望么？来看看专家怎么说。 + +![CIO_Big Data Decisions_2](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO_Big%20Data%20Decisions_2.png?itok=Y5zMHxf8 "CIO_Big Data Decisions_2") + +如果你想对容器在未来的发展方向有一个整体把握，那么你一定要跟着钱走，看看钱都投在了哪里。当然了，有很多很多的钱正在投入容器的进一步发展。相关研究预计 2020 年容器技术的投入将占有 [27 亿美元][4] 的市场份额 。而在 2016 年，容器相关技术投入的总额为 7.62 亿美元，只有 2020 年投入预计的三分之一。巨额投入的背后是一些显而易见的基本因素，包括容器化的迅速增长以及并行化的大趋势。随着容器被大面积推广和使用，容器编排管理也会被理所当然的推广应用起来。 + +来自 [_The new stack_][5] 的调研数据表明，容器的推广使用是编排管理被推广的主要的催化剂。根据调研参与者的反馈数据，在已经将容器技术使用到生产环境中的使用者里，有六成正在将 kubernetes（k8s）编排管理广泛的应用在生产环境中,另外百分之十九的人员则表示他们已经处于部署 k8s 的初级阶段。在容器部署初期的使用者当中，虽然只有百分之五的人员表示已经在使用 K8s ,但是百分之五十八的人员表示他们正在计划和准备使用 K8s。总而言之，容器和 Kuebernetes 的关系就好比是鸡和蛋一样，相辅相成紧密关联。众多专家一致认为编排管理工具对容器的[长周期管理][6] 以及其在市场中的发展有至关重要的作用。正如 [Cockroach 实验室][7] 的 Alex Robinson 所说，容器编排管理被更广泛的拓展和应用是一个总体的大趋势。毫无疑问，这是一个正在快速演变的领域，且未来潜力无穷。鉴于此，我们对罗宾逊和其他的一些容器的实际使用和推介者做了采访，来从他们作为容器技术的践行者的视角上展望一下容器编排以及 k8s 的下一步发展。 + +### **容器编排将被主流接受*** + +像任何重要技术的转型一样，我们就像是处在一个高崖之上一般，在经过了初期步履蹒跚的跋涉之后将要来到一望无际的广袤平原。广大的新天地和平实真切的应用需求将会让这种新技术在主流应用中被迅速推广，尤其是在大企业环境中。正如 Alex Robinson 说的那样，容器技术的淘金阶段已经过去，早期的技术革新创新正在减速，随之而来的则是市场对容器技术的稳定性和可用性的强烈需求。这意味着未来我们将不会再见到大量的新的编排管理系统的涌现，而是会看到容器技术方面更多的安全解决方案，更丰富的管理工具，以及基于目前主流容器编排系统的更多的新特性。 + +### **更好的易用性** + +人们将在简化容器的部署方面下大功夫，因为容器部署的初期工作对很多公司和组织来说还是比较复杂的，尤其是容器的[长期管理维护][8]更是需要投入大量的精力。正如 [Codemill AB][9] 公司的 My Karlsson 所说，容器编排技术还是太复杂了，这导致很多使用者难以娴熟驾驭和充分利用容器编排的功能。很多容器技术的新用户都需要花费很多精力，走很多弯路，才能搭建小规模的，单个的，被隔离的容器系统。这种现象在那些没有针对容器技术设计和优化的应用中更为明显。在简化容器编排管理方面有很多优化可以做，这些优化和改造将会使容器技术更加具有可用性。 + +### **在 hybrid cloud 以及 multi-cloud 技术方面会有更多侧重*** + +随着容器和容器编排技术被越来越多的使用，更多的组织机构会选择扩展他们现有的容器技术的部署，从之前的把非重要系统部署在单一环境的使用情景逐渐过渡到更加[复杂的使用情景][10]。对很多公司来说，这意味着他们必须开始学会在 [hybrid cloud][11] 和 [muilti-cloud][12] 的环境下，全局化的去管理那些容器化的应用和微服务。正如红帽 [Openshift 部门产品战略总监][14] [Brian Gracely][13] 所说,容器和 k8s 技术的使用使得我们成功的实现了混合云以及应用的可移植性。结合 Open Service Broker API 的使用，越来越多的结合私有云和公有云资源的新应用将会涌现出来。 +据 [CloudBees][15] 公司的高级工程师 Carlos Sanchez 分析，联合服务（Federation）将会得到极大推动，使一些诸如多地区部署和多云部署等的备受期待的新特性成为可能。 + +**[ 想知道 CIO 们对 hybrid cloud 和 multi cloud 的战略构想么? 请参看我们的这条相关资源， **[**Hybrid Cloud: The IT leader's guide**][16]**. ]** + +### **平台和工具的持续整合及加强** + +对任何一种科技来说，持续的整合和加强从来都是大势所趋; 容器编排管理技术在这方面也不例外。来自 [Sumo Logic][17] 的首席分析师 Ben Newton 表示，随着容器化渐成主流，软件工程师们正在很少数的一些技术上做持续整合加固的工作，来满足他们的一些微应用的需求。容器和 K8s 将会毫无疑问的成为容器编排管理方面的主流平台，并轻松碾压其他的一些小众平台方案。因为 K8s 提供了一个相当清晰的可以摆脱各种特有云生态的途径，K8s 将被大量公司使用，逐渐形成一个不依赖于某个特定云服务的“中立云”（cloud-neutral）。 + +### ** K8s 的下一站** + +来自 [Alcide][18] 的 CTO 和联合创始人 Gadi Naor 表示，k8s 将会是一个有长期和远景发展的技术，虽然我们的社区正在大力推广和发展 k8s，k8s 仍有很长的路要走。 +专家们对[日益流行的 k8s 平台][19]也作出了以下一些预测： + +**_来自 Alcide 的 Gadi Naor 表示:_** “运营商会持续演进并趋于成熟，直到在 k8s 上运行的应用可以完全自治。利用 [OpenTracing][20] 和诸如 [istio][21] 技术的 service mesh 架构，在 k8s 上部署和监控微应用将会带来很多新的可能性。” + +**_来自 Red Hat 的 Brian Gracely 表示:_** “k8s 所支持的应用的种类越来越多。今后在 k8s 上，你不仅可以运行传统的应用程序，还可以运行原生的云应用，大数据应用以及 HPC 或者基于 GPU 运算的应用程序，这将为灵活的架构设计带来无限可能。” + +**_来自 Sumo Logic 的 Ben Newton 表示:_** “随着 k8s 成为一个具有统治地位的平台，我预计更多的操作机制将会被统一化，尤其是 k8s 将和第三方管理和监控平台融合起来。” + +**_来自 CloudBees 的 Carlos Sanchez 表示:_** ”在不久的将来我们就能看到不依赖于 Docker 而使用其他运行时环境的系统，这将会有助于消除任何可能的 lock-in 情景“ [小编提示：[CRI-O][22] 就是一个可以借鉴的例子。]“而且我期待将来会出现更多的针对企业环境的存储服务新特性，包括数据快照以及在线的磁盘容量的扩展。” + +**_来自小强实验室（Cockroach Labs）的 Alex Robinson 表示:_** “k8s 社区正在讨论的一个重大发展议题就是加强对[有状态程序][23]的管理。目前在 k8s 平台下,实现状态管理仍然非常困难，除非你所使用的云服务商可以提供远程固定磁盘。现阶段也有很多人在多方面试图改善这个状况，包括在 k8s 平台内部以及在外部服务商一端做出的一些改进。” +------------------------------------------------------------------------------- + +via: https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next + +作者：[Kevin Casey ][a] +译者：[yunfengHe](https://github.com/yunfengHe) +校对：[校对者ID](https://github.com/校对者ID) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]:https://enterprisersproject.com/user/kevin-casey +[1]:https://enterprisersproject.com/article/2017/11/kubernetes-numbers-10-compelling-stats +[2]:https://enterprisersproject.com/article/2017/11/how-enterprise-it-uses-kubernetes-tame-container-complexity +[3]:https://enterprisersproject.com/article/2017/11/5-kubernetes-success-tips-start-smart?sc_cid=70160000000h0aXAAQ +[4]:https://451research.com/images/Marketing/press_releases/Application-container-market-will-reach-2-7bn-in-2020_final_graphic.pdf +[5]:https://thenewstack.io/ +[6]:https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul +[7]:https://www.cockroachlabs.com/ +[8]:https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul +[9]:https://codemill.se/ +[10]:https://www.redhat.com/en/challenges/integration?intcmp=701f2000000tjyaAAA +[11]:https://enterprisersproject.com/hybrid-cloud +[12]:https://enterprisersproject.com/article/2017/7/multi-cloud-vs-hybrid-cloud-whats-difference +[13]:https://enterprisersproject.com/user/brian-gracely +[14]:https://www.redhat.com/en +[15]:https://www.cloudbees.com/ +[16]:https://enterprisersproject.com/hybrid-cloud?sc_cid=70160000000h0aXAAQ +[17]:https://www.sumologic.com/ +[18]:http://alcide.io/ +[19]:https://enterprisersproject.com/article/2017/10/how-explain-kubernetes-plain-english +[20]:http://opentracing.io/ +[21]:https://istio.io/ +[22]:http://cri-o.io/ +[23]:https://opensource.com/article/17/2/stateful-applications +[24]:https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next?rate=PBQHhF4zPRHcq2KybE1bQgMkS2bzmNzcW2RXSVItmw8 +[25]:https://enterprisersproject.com/user/kevin-casey From 3e1a2beb329d2f4810e84366a121dfda5f6b133a Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Sat, 2 Dec 2017 23:39:51 +0800 Subject: [PATCH 02/16] translated, modified --- .../tech/20171120 Containers and Kubernetes Whats next.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translated/tech/20171120 Containers and Kubernetes Whats next.md b/translated/tech/20171120 Containers and Kubernetes Whats next.md index a6e7b8f7e6..62a81dc9fa 100644 --- a/translated/tech/20171120 Containers and Kubernetes Whats next.md +++ b/translated/tech/20171120 Containers and Kubernetes Whats next.md @@ -40,7 +40,7 @@ **_来自 CloudBees 的 Carlos Sanchez 表示:_** ”在不久的将来我们就能看到不依赖于 Docker 而使用其他运行时环境的系统，这将会有助于消除任何可能的 lock-in 情景“ [小编提示：[CRI-O][22] 就是一个可以借鉴的例子。]“而且我期待将来会出现更多的针对企业环境的存储服务新特性，包括数据快照以及在线的磁盘容量的扩展。” -**_来自小强实验室（Cockroach Labs）的 Alex Robinson 表示:_** “k8s 社区正在讨论的一个重大发展议题就是加强对[有状态程序][23]的管理。目前在 k8s 平台下,实现状态管理仍然非常困难，除非你所使用的云服务商可以提供远程固定磁盘。现阶段也有很多人在多方面试图改善这个状况，包括在 k8s 平台内部以及在外部服务商一端做出的一些改进。” +**_来自小强实验室（Cockroach Labs）的 Alex Robinson 表示:_“**k8s 社区正在讨论的一个重大发展议题就是加强对[有状态程序][23]的管理。目前在 k8s 平台下,实现状态管理仍然非常困难，除非你所使用的云服务商可以提供远程固定磁盘。现阶段也有很多人在多方面试图改善这个状况，包括在 k8s 平台内部以及在外部服务商一端做出的一些改进。” ------------------------------------------------------------------------------- via: https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next From 4cec0af25f1a388903a7245c40a4b9acdf8511a3 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Sat, 2 Dec 2017 23:46:55 +0800 Subject: [PATCH 03/16] modified v2 --- .../tech/20171120 Containers and Kubernetes Whats next.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/translated/tech/20171120 Containers and Kubernetes Whats next.md b/translated/tech/20171120 Containers and Kubernetes Whats next.md index 62a81dc9fa..aab7d76564 100644 --- a/translated/tech/20171120 Containers and Kubernetes Whats next.md +++ b/translated/tech/20171120 Containers and Kubernetes Whats next.md @@ -8,7 +8,7 @@ 来自 [_The new stack_][5] 的调研数据表明，容器的推广使用是编排管理被推广的主要的催化剂。根据调研参与者的反馈数据，在已经将容器技术使用到生产环境中的使用者里，有六成正在将 kubernetes（k8s）编排管理广泛的应用在生产环境中,另外百分之十九的人员则表示他们已经处于部署 k8s 的初级阶段。在容器部署初期的使用者当中，虽然只有百分之五的人员表示已经在使用 K8s ,但是百分之五十八的人员表示他们正在计划和准备使用 K8s。总而言之，容器和 Kuebernetes 的关系就好比是鸡和蛋一样，相辅相成紧密关联。众多专家一致认为编排管理工具对容器的[长周期管理][6] 以及其在市场中的发展有至关重要的作用。正如 [Cockroach 实验室][7] 的 Alex Robinson 所说，容器编排管理被更广泛的拓展和应用是一个总体的大趋势。毫无疑问，这是一个正在快速演变的领域，且未来潜力无穷。鉴于此，我们对罗宾逊和其他的一些容器的实际使用和推介者做了采访，来从他们作为容器技术的践行者的视角上展望一下容器编排以及 k8s 的下一步发展。 -### **容器编排将被主流接受*** +### **容器编排将被主流接受** 像任何重要技术的转型一样，我们就像是处在一个高崖之上一般，在经过了初期步履蹒跚的跋涉之后将要来到一望无际的广袤平原。广大的新天地和平实真切的应用需求将会让这种新技术在主流应用中被迅速推广，尤其是在大企业环境中。正如 Alex Robinson 说的那样，容器技术的淘金阶段已经过去，早期的技术革新创新正在减速，随之而来的则是市场对容器技术的稳定性和可用性的强烈需求。这意味着未来我们将不会再见到大量的新的编排管理系统的涌现，而是会看到容器技术方面更多的安全解决方案，更丰富的管理工具，以及基于目前主流容器编排系统的更多的新特性。 @@ -16,7 +16,7 @@ 人们将在简化容器的部署方面下大功夫，因为容器部署的初期工作对很多公司和组织来说还是比较复杂的，尤其是容器的[长期管理维护][8]更是需要投入大量的精力。正如 [Codemill AB][9] 公司的 My Karlsson 所说，容器编排技术还是太复杂了，这导致很多使用者难以娴熟驾驭和充分利用容器编排的功能。很多容器技术的新用户都需要花费很多精力，走很多弯路，才能搭建小规模的，单个的，被隔离的容器系统。这种现象在那些没有针对容器技术设计和优化的应用中更为明显。在简化容器编排管理方面有很多优化可以做，这些优化和改造将会使容器技术更加具有可用性。 -### **在 hybrid cloud 以及 multi-cloud 技术方面会有更多侧重*** +### **在 hybrid cloud 以及 multi-cloud 技术方面会有更多侧重** 随着容器和容器编排技术被越来越多的使用，更多的组织机构会选择扩展他们现有的容器技术的部署，从之前的把非重要系统部署在单一环境的使用情景逐渐过渡到更加[复杂的使用情景][10]。对很多公司来说，这意味着他们必须开始学会在 [hybrid cloud][11] 和 [muilti-cloud][12] 的环境下，全局化的去管理那些容器化的应用和微服务。正如红帽 [Openshift 部门产品战略总监][14] [Brian Gracely][13] 所说,容器和 k8s 技术的使用使得我们成功的实现了混合云以及应用的可移植性。结合 Open Service Broker API 的使用，越来越多的结合私有云和公有云资源的新应用将会涌现出来。 据 [CloudBees][15] 公司的高级工程师 Carlos Sanchez 分析，联合服务（Federation）将会得到极大推动，使一些诸如多地区部署和多云部署等的备受期待的新特性成为可能。 @@ -38,9 +38,9 @@ **_来自 Sumo Logic 的 Ben Newton 表示:_** “随着 k8s 成为一个具有统治地位的平台，我预计更多的操作机制将会被统一化，尤其是 k8s 将和第三方管理和监控平台融合起来。” -**_来自 CloudBees 的 Carlos Sanchez 表示:_** ”在不久的将来我们就能看到不依赖于 Docker 而使用其他运行时环境的系统，这将会有助于消除任何可能的 lock-in 情景“ [小编提示：[CRI-O][22] 就是一个可以借鉴的例子。]“而且我期待将来会出现更多的针对企业环境的存储服务新特性，包括数据快照以及在线的磁盘容量的扩展。” +**_来自 CloudBees 的 Carlos Sanchez 表示:_** “在不久的将来我们就能看到不依赖于 Docker 而使用其他运行时环境的系统，这将会有助于消除任何可能的 lock-in 情景“ [小编提示：[CRI-O][22] 就是一个可以借鉴的例子。]“而且我期待将来会出现更多的针对企业环境的存储服务新特性，包括数据快照以及在线的磁盘容量的扩展。” -**_来自小强实验室（Cockroach Labs）的 Alex Robinson 表示:_“**k8s 社区正在讨论的一个重大发展议题就是加强对[有状态程序][23]的管理。目前在 k8s 平台下,实现状态管理仍然非常困难，除非你所使用的云服务商可以提供远程固定磁盘。现阶段也有很多人在多方面试图改善这个状况，包括在 k8s 平台内部以及在外部服务商一端做出的一些改进。” +**_来自 Cockroach Labs 的 Alex Robinson 表示:_** “ k8s 社区正在讨论的一个重大发展议题就是加强对[有状态程序][23]的管理。目前在 k8s 平台下,实现状态管理仍然非常困难，除非你所使用的云服务商可以提供远程固定磁盘。现阶段也有很多人在多方面试图改善这个状况，包括在 k8s 平台内部以及在外部服务商一端做出的一些改进。” ------------------------------------------------------------------------------- via: https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next From a9ff43c82f80c4bf29a282d8cdf6ea5aaec034da Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Sat, 2 Dec 2017 23:50:05 +0800 Subject: [PATCH 04/16] modified v3 --- .../tech/20171120 Containers and Kubernetes Whats next.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translated/tech/20171120 Containers and Kubernetes Whats next.md b/translated/tech/20171120 Containers and Kubernetes Whats next.md index aab7d76564..7d96d3350c 100644 --- a/translated/tech/20171120 Containers and Kubernetes Whats next.md +++ b/translated/tech/20171120 Containers and Kubernetes Whats next.md @@ -27,7 +27,7 @@ 对任何一种科技来说，持续的整合和加强从来都是大势所趋; 容器编排管理技术在这方面也不例外。来自 [Sumo Logic][17] 的首席分析师 Ben Newton 表示，随着容器化渐成主流，软件工程师们正在很少数的一些技术上做持续整合加固的工作，来满足他们的一些微应用的需求。容器和 K8s 将会毫无疑问的成为容器编排管理方面的主流平台，并轻松碾压其他的一些小众平台方案。因为 K8s 提供了一个相当清晰的可以摆脱各种特有云生态的途径，K8s 将被大量公司使用，逐渐形成一个不依赖于某个特定云服务的“中立云”（cloud-neutral）。 -### ** K8s 的下一站** +### **K8s 的下一站** 来自 [Alcide][18] 的 CTO 和联合创始人 Gadi Naor 表示，k8s 将会是一个有长期和远景发展的技术，虽然我们的社区正在大力推广和发展 k8s，k8s 仍有很长的路要走。 专家们对[日益流行的 k8s 平台][19]也作出了以下一些预测： From dbb695755875154173f3f59b9ac51d22d077785e Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Sat, 2 Dec 2017 23:51:49 +0800 Subject: [PATCH 05/16] modified yunfengHe final --- translated/tech/20171120 Containers and Kubernetes Whats next.md | 1 + 1 file changed, 1 insertion(+) diff --git a/translated/tech/20171120 Containers and Kubernetes Whats next.md b/translated/tech/20171120 Containers and Kubernetes Whats next.md index 7d96d3350c..5ed099c170 100644 --- a/translated/tech/20171120 Containers and Kubernetes Whats next.md +++ b/translated/tech/20171120 Containers and Kubernetes Whats next.md @@ -41,6 +41,7 @@ **_来自 CloudBees 的 Carlos Sanchez 表示:_** “在不久的将来我们就能看到不依赖于 Docker 而使用其他运行时环境的系统，这将会有助于消除任何可能的 lock-in 情景“ [小编提示：[CRI-O][22] 就是一个可以借鉴的例子。]“而且我期待将来会出现更多的针对企业环境的存储服务新特性，包括数据快照以及在线的磁盘容量的扩展。” **_来自 Cockroach Labs 的 Alex Robinson 表示:_** “ k8s 社区正在讨论的一个重大发展议题就是加强对[有状态程序][23]的管理。目前在 k8s 平台下,实现状态管理仍然非常困难，除非你所使用的云服务商可以提供远程固定磁盘。现阶段也有很多人在多方面试图改善这个状况，包括在 k8s 平台内部以及在外部服务商一端做出的一些改进。” + ------------------------------------------------------------------------------- via: https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next From 5774a55c1fd83652a93db920b4bf3e688eaa2506 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Sat, 2 Dec 2017 23:58:22 +0800 Subject: [PATCH 06/16] translated yunfengHe --- ...20 Containers and Kubernetes Whats next.md | 98 ------------------- 1 file changed, 98 deletions(-) delete mode 100644 sources/tech/20171120 Containers and Kubernetes Whats next.md diff --git a/sources/tech/20171120 Containers and Kubernetes Whats next.md b/sources/tech/20171120 Containers and Kubernetes Whats next.md deleted file mode 100644 index 1a8400d7cd..0000000000 --- a/sources/tech/20171120 Containers and Kubernetes Whats next.md +++ /dev/null @@ -1,98 +0,0 @@ -YunfengHe Translating -Containers and Kubernetes: What's next? -============================================================ - -### What's ahead for container orchestration and Kubernetes? Here's an expert peek - -![CIO_Big Data Decisions_2](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO_Big%20Data%20Decisions_2.png?itok=Y5zMHxf8 "CIO_Big Data Decisions_2") - -If you want a basic idea of where containers are headed in the near future, follow the money. There’s a lot of it: 451 Research projects that the overall market for containers will hit roughly [$2.7 billion in 2020][4], a 3.5-fold increase from the $762 million spent on container-related technology in 2016. - -There’s an obvious fundamental factor behind such big numbers: Rapidly increasing containerization. The parallel trend: As container adoption grows, so will container _orchestration_ adoption. - -As recent survey data from [_The New Stack_][5] indicates, container adoption is the most significant catalyst of orchestration adoption: 60 percent of respondents who’ve deployed containers broadly in production report they’re also using Kubernetes widely in production. Another 19 percent of respondents with broad container deployments in production were in the initial stages of broad Kubernetes adoption. Meanwhile, just 5 percent of those in the initial phases of deploying containers in production environments were using Kubernetes broadly – but 58 percent said they were preparing to do so. It’s a chicken-and-egg relationship. - - -Most experts agree that an orchestration tool is essential to the scalable [long-term management of containers][6] – and corresponding developments in the marketplace. “The next trends in container orchestration are all focused on broadening adoption,” says Alex Robinson, software engineer at [Cockroach Labs][7]. - -This is a quickly shifting landscape, one that is just starting to realize its future potential. So we checked in with Robinson and other practitioners to get their boots-on-the-ground perspective on what’s next in container orchestration – and for Kubernetes itself. - -### **Container orchestration shifts to mainstream** - -We’re at the precipice common to most major technology shifts, where we transition from the careful steps of early adoption to cliff-diving into commonplace use. That will create new demand for the plain-vanilla requirements that make mainstream adoption easier, especially in large enterprises. - -“The gold rush phase of early innovation has slowed down and given way to a much stronger focus on stability and usability,” Robinson says. “This means we'll see fewer major announcements of new orchestration systems, and more security options, management tools, and features that make it easier to take advantage of the flexibility already inherent in the major orchestration systems.” - -### **Reduced complexity** - -On a related front, expect an intensifying effort to cut back on the complexity that some organizations face when taking their first plunge into container orchestration. As we’ve covered before, deploying a container might be “easy,” but [managing containers long-term ][8]requires more care. - -“Today, container orchestration is too complex for many users to take full advantage,” says My Karlsson, developer at [Codemill AB][9]. “New users are often struggling just to get single or small-size container configurations running in isolation, especially when applications are not originally designed for it. There are plenty of opportunities to simplify the orchestration of non-trivial applications and make the technology more accessible.” - -### **Increasing focus on hybrid cloud and multi-cloud** - -As adoption of containers and container orchestration grows, more organizations will scale from a starting point of, say, running non-critical workloads in a single environment to more [complex use cases][10] across multiple environments. For many companies, that will mean managing containerized applications (and particularly containerized microservices) across [hybrid cloud][11] and [multi-cloud][12] environments, often globally. - -"Containers and Kubernetes have made hybrid cloud and application portability a reality,” says [Brian Gracely][13], director of [Red Hat][14] OpenShift product strategy. “Combined with the Open Service Broker, we expect to see an explosion of new applications that combine private and public cloud resources." - -“I believe that federation will get a push, enabling much-wanted features such as seamless multi-region and multi-cloud deployments,” says Carlos Sanchez, senior software engineer at [CloudBees][15]. - -**[ Want CIO wisdom on hybrid cloud and multi-cloud strategy? See our related resource, **[**Hybrid Cloud: The IT leader's guide**][16]**. ]** - -### **Continued consolidation of platforms and tools** - -Technology consolidation is common trend; container orchestration is no exception. - -“As containerization goes mainstream, engineers are consolidating on a very small number of technologies to run their [microservices and] containers and Kubernetes will become the dominant container orchestration platform, far outstripping other platforms,” says Ben Newton, analytics lead at [Sumo Logic][17]. “Companies will adopt Kubernetes to drive a cloud-neutral approach as Kubernetes provides a reasonably clear path to reduce dependence on [specific] cloud ecosystems.**”** - -### **Speaking of Kubernetes, what’s next?** - -"Kubernetes is here for the long haul, and the community driving it is doing great job – but there's lots ahead,” says Gadi Naor, CTO and co-founder of [Alcide][18]. Our experts shared several predictions specific to [the increasingly popular Kubernetes platform][19]: - - **_Gadi Naor at Alcide:_** “Operators will continue to evolve and mature, to a point where applications running on Kubernetes will become fully self-managed. Deploying and monitoring microservices on top of Kubernetes with [OpenTracing][20] and service mesh frameworks such as [istio][21] will help shape new possibilities.” - - **_Brian Gracely at Red Hat:_** “Kubernetes continues to expand in terms of the types of applications it can support. When you can run traditional applications, cloud-native applications, big data applications, and HPC or GPU-centric applications on the same platform, it unlocks a ton of architectural flexibility.” - - **_Ben Newton at Sumo Logic: _ “**As Kubernetes becomes more dominant, I would expect to see more normalization of the operational mechanisms – particularly integrations into third-party management and monitoring platforms.” - - **_Carlos Sanchez at CloudBees: _** “In the immediate future there is the ability to run without Docker, using other runtimes...to remove any lock-in. [Editor’s note: [CRI-O][22], for example, offers this ability.] “Also, [look for] storage improvements to support enterprise features like data snapshotting and online volume resizing.” - - - **_Alex Robinson at Cockroach Labs: _ “**One of the bigger developments happening in the Kubernetes community right now is the increased focus on managing [stateful applications][23]. Managing state in Kubernetes right now is very difficult if you aren't running in a cloud that offers remote persistent disks, but there's work being done on multiple fronts [both inside Kubernetes and by external vendors] to improve this.” - --------------------------------------------------------------------------------- - -via: https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next - -作者：[Kevin Casey ][a] -译者：[译者ID](https://github.com/译者ID) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:https://enterprisersproject.com/user/kevin-casey -[1]:https://enterprisersproject.com/article/2017/11/kubernetes-numbers-10-compelling-stats -[2]:https://enterprisersproject.com/article/2017/11/how-enterprise-it-uses-kubernetes-tame-container-complexity -[3]:https://enterprisersproject.com/article/2017/11/5-kubernetes-success-tips-start-smart?sc_cid=70160000000h0aXAAQ -[4]:https://451research.com/images/Marketing/press_releases/Application-container-market-will-reach-2-7bn-in-2020_final_graphic.pdf -[5]:https://thenewstack.io/ -[6]:https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul -[7]:https://www.cockroachlabs.com/ -[8]:https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul -[9]:https://codemill.se/ -[10]:https://www.redhat.com/en/challenges/integration?intcmp=701f2000000tjyaAAA -[11]:https://enterprisersproject.com/hybrid-cloud -[12]:https://enterprisersproject.com/article/2017/7/multi-cloud-vs-hybrid-cloud-whats-difference -[13]:https://enterprisersproject.com/user/brian-gracely -[14]:https://www.redhat.com/en -[15]:https://www.cloudbees.com/ -[16]:https://enterprisersproject.com/hybrid-cloud?sc_cid=70160000000h0aXAAQ -[17]:https://www.sumologic.com/ -[18]:http://alcide.io/ -[19]:https://enterprisersproject.com/article/2017/10/how-explain-kubernetes-plain-english -[20]:http://opentracing.io/ -[21]:https://istio.io/ -[22]:http://cri-o.io/ -[23]:https://opensource.com/article/17/2/stateful-applications -[24]:https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next?rate=PBQHhF4zPRHcq2KybE1bQgMkS2bzmNzcW2RXSVItmw8 -[25]:https://enterprisersproject.com/user/kevin-casey \ No newline at end of file From 6f416e98cf6204b97ffd5e3d5dd0a6c3039f46ff Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Fri, 15 Dec 2017 00:09:36 +0800 Subject: [PATCH 07/16] =?UTF-8?q?The=20One=20in=20Which=20I=20Call=20Out?= =?UTF-8?q?=20Hacker=20News,=20=E6=A0=A1=E5=AF=B9=E5=AE=8C=E6=AF=95?= =?UTF-8?q?=EF=BC=8C=E6=A0=BC=E5=BC=8F=E9=9C=80=E8=A6=81=E5=86=8D=E6=A0=A1?= =?UTF-8?q?=E5=AF=B9=E6=9B=B4=E6=94=B9=E4=B8=80=E8=BE=B9.=20=E6=BA=90?= =?UTF-8?q?=E8=8B=B1=E6=96=87md=E6=96=87=E4=BB=B6=E4=B8=A2=E5=A4=B1?= =?UTF-8?q?=EF=BC=8C=E6=97=A0=E6=B3=95=E8=B0=83=E6=95=B4md=E5=BC=95?= =?UTF-8?q?=E7=94=A8=E3=80=82?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...The One in Which I Call Out Hacker News.md | 108 ++++++------------ 1 file changed, 38 insertions(+), 70 deletions(-) diff --git a/translated/tech/20090701 The One in Which I Call Out Hacker News.md b/translated/tech/20090701 The One in Which I Call Out Hacker News.md index 670be95353..30e796cb8a 100644 --- a/translated/tech/20090701 The One in Which I Call Out Hacker News.md +++ b/translated/tech/20090701 The One in Which I Call Out Hacker News.md @@ -1,99 +1,67 @@ -我号召黑客新闻的理由之一 +因为这个，我找 Hacker News 期刊理论了一番 + 实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ -不，你没有。 -我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间，这是程序员永远的 -乐观主义。 -- Owen Astrachan 教授于 2004 年 2 月 23 日在 CPS 108 上的讲座 +不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员永远的乐观主义。 +- 出自 Owen Astrachan 教授于 2004 年 2 月 23 日在 CPS 108 上的讲座 -指责开源软件的使用存在着高昂的代价已经不是一个新论点了，它之前就被提过，而且说的比我更有信服力，即使一些人已经在高度赞扬开源软件的运作。 -这种事为什么会重复发生？ +指责开源软件总是离奇难用已经不是一个新论点了。这样的论点之前就被很多比我更为雄辩的人提及过，甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？ -在周一的黑客新闻上，我愉悦地看着某些人一边说写 Stack Overflow 简单的简直搞笑，一边通过允许七月第四个周末之后的克隆来开始备份他们的提问。 -其他的声明中也指出现存的克隆是一个好的出发点。 +在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为编写代码实现一个StackOverflow可以简单到搞笑的程度，并自信的声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品就已经是一个很好的例证了。 -让我们假设，为了争辩，你觉得将自己的 Stack Overflow 通过 ASP.NET 和 MVC 克隆是正确的，然后被一块廉价的手表和一个小型俱乐部头领忽悠之后， -决定去手动拷贝你 Stack Overflow 的源代码，一页又一页，所以你可以逐字逐句地重新输入，我们同样会假定你像我一样打字，很酷的有 100 WPM -（差不多每秒8个字符），不和我一样的话，你不会犯错。 +秉承着自由讨论的精神，我们来假设一个场景。你在思考之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词(也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少80个小时的时间。 - Stack Overflow 的 *.cs、*.sql、*.css、*.js 和 *.aspx 文件大约 2.3 MB，因此如果你想将这些源代码输进电脑里去的话，即使你不犯错也需要大约 80 个小时。 +或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭源 StackOverflow 代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄源 StackOverflow 代码用时的十倍时间来让我自己写 StackOverflow, 我可是打死也做不到。 -除非......当然，你是不会那样做的：你打算从头开始实现 Stack Overflow 。所以即使我们假设，你花了十倍的时间去设计、输出，然后调试你自己的实现而不是去拷 -贝已有的那份，那已经让你已经编译了好几个星期。我不知道你，但是我可以承认我写的新代码大大小于我复制的现有代码的十分之一。 +好的，我知道你在听到这些假设的时候已经开始觉得泄气了。*你在想，如果不是全部实现，而只是实现 StackOverflow 大部分的功能呢？这总归会容易很多了吧* -好，ok，我听见你松了口气。所以不是全部。但是我可以做大部分。 +好的，问题是什么是大部分功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题和其答案的投票系统来显示大家对某个答案是赞同还是反对。只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且 +与 Markdown 接合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的那个超棒的编辑器 ）。你还需要为所有控件购买或者设计一些小图标小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。 -行，所以什么是大部分？这只是询问和回答问题，这个部分很简单。那么，除了你必须实现对问题和答案投票、赞同还是反对，而且提问者应该能够去接收每一个问题的 -单一答案。你不能让人们赞同或者反对他们自己的回答。所以你需要去阻止。你需要去确保用户在一定的时间内不会赞同或反对其他用户太多次。以预防垃圾邮件， -你可能也需要去实现一个垃圾邮件过滤器，即使在一个基本的设计里，也要考虑到这一点。而且还需要去支持用户图标。并且你将不得不寻找一个自己真正信任的并且 -与 markdown 接合很好的 HTML 库（当然，你确实希望重新使用那个令人敬畏的编辑器 Stack Overflow ），你还需要为所有控件购买，设计或查找小部件，此外 -你至少需要一个基本的管理界面，以便用户可以调节，并且你需要实现可扩展的业务量，以便能稳定地给用户越来越多的功能去实现他们想做的。 +但是如果你实现了以上所有功能，可以说你就已经把要做的都做完了。 -如果你这样做了，你可以完成它。 +除非...除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现回答的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移冷却下去沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登陆事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和徽章（Badge）。你需要去显示用户的 Karma 历史，点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 slashdot，reddit 或是 StackOverflow 这些动作影响到。 -除了...除了全文检索外，特别是它在“寻找问题”功能中的表现，这是必不可少的。然后用户的基本信息，和回答的意见，然后有一个主要展示你的重要问题， -但是它会稳定的冒泡式下降。另外你需要去实现奖励，并支持每个用户的多个 OpenID 登录，然后为相关的事件发送邮件通知，并添加一个标签系统， -接着允许管理员通过一个不错的图形界面配置徽章。你需要去显示用户的 karma 历史，点赞和差评。整个事情的规模都非常好，因为它随时都可以被 - slashdotted、reddited 或是 Stack Overflow 。 +在这之后！你会以为你基本已经大功告成了！ -在这之后！你就已经完成了！ +...为了产品的完整性，在上面所述的工作都完成之后，你又奋不顾身的去实现了升级功能，界面语言的国际化，Karma 值上限，以及让网站更专业的CSS设计，AJAX，还有那些看起来理所当然做起来却让人吐血的功能和特性。如果你不是真的动手来尝试做一个和 StackOverflow 一摸一样的系统，你肯定不会意识到在整个程序设计实施的过程中，你会踩到无数的鬼才会知道的大坑。 -...在正确地实现升级、国际化、业绩上限和一个 css 设计之后，使你的站点看起来不像是一个屁股，上面的大部分 AJAX 版本和 G-d 知道什么会同样潜伏 -在你所信任的界面下，但是当你开始做一个真正的克隆的时候，就会遇到它。 +那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？ -告诉我：这些功能中哪个是你感觉可以削减而让它仍然是一个引人注目的产品，哪些是大部分网站之下的呢？哪个你可以剔除呢？ +正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也正是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。因为看似简单的功能，做起来却总是布满荆棘。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码 -开发者因为开源软件的使用是一个可怕的痛苦这样一个相同的理由认为克隆一个像 Stack Overflow 的站点很简单。当你把一个开发者放在 Stack Overflow 前面， -他们并不真的看到 Stack Overflow，他们实际上看的是这些: create table QUESTION (ID identity primary key, - TITLE varchar(255), --- 为什么我知道你认为是 255 - BODY text, - UPVOTES integer not null default 0, - DOWNVOTES integer not null default 0, - USER integer references USER(ID)); + TITLE varchar(255), --- 为什么我知道你认为是 255 + BODY text, + UPVOTES integer not null default 0, + DOWNVOTES integer not null default 0, + USER integer references USER(ID)); create table RESPONSE (ID identity primary key, - BODY text, - UPVOTES integer not null default 0, - DOWNVOTES integer not null default 0, - QUESTION integer references QUESTION(ID)) + BODY text, + UPVOTES integer not null default 0, + DOWNVOTES integer not null default 0, + QUESTION integer references QUESTION(ID)) -如果你告诉一个开发者去复制 Stack Overflow ，进入他脑海中的就是上面的两个 SQL 表和足够的 HTML 文件来显示它们，而不用格式化，这在一个周末里是完全 -可以实现的，聪明的人会意识到他们需要实现登陆、注销和评论，点赞需要绑定到用户。但是这在一个周末内仍然是完全可行的。这仅仅是在 SQL 后端里加上两张 -左右的表，而 HTML 则用来展示内容，使用像 Django 这样的框架，你甚至可以免费获得基本的用户和评论。 -但是那不是和 Stack Overflow 相关的，无论你对 Stack Overflow 的感受如何，大多数访问者似乎都认为用户体验从头到尾都很流畅，他们感觉他们和一个 -好产品相互影响。即使我没有更好的了解，我也会猜测 Stack Overflow 在数据库模式方面取得了持续的成功-并且有机会去阅读 Stack Overflow 的源代码， -我知道它实际上有多么的小，这些是一个极大的 spit 和 Polish 的集合，成为了一个具有高可用性的主要网站，一个开发者，问一个东西被克隆有多难， -仅仅不认为和 Polish 相关，因为 Polish 是实现结果附带的。 +如果你让这些开发者去实现 Stack Overflow，进入他脑海中的就是上面的两个SQL表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登陆和注销功能，评论功能，投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登陆和评论的功能。 -这就是为什么 Stack Overflow 的开放源代码克隆会失败，即使一些人在设法实现大部分 Stack Overflow 的“规范”，也会有一些关键区域会将他们绊倒， -举个例子，如果你把目标市场定在了终端用户上，你要么需要一个图形界面去配置规则，要么聪明的开发者会决定哪些徽章具有足够的通用性，去继续所有的 -安装，实际情况是，开发者发牢骚和抱怨你不能实现一个真实的综合性的像 badges 的图形用户界面，然后 bikeshed 任何的建议，为因为标准的 badges -在范围内太远，他们会迅速避开选择其他方向，他们最后会带着相同的有 bug 追踪器的解决方案赶上，就像他们工作流程的概要使用一样： -开发者通过任意一种方式实现一个通用的机制，任何一个人完全都能轻松地使用 Python、PHP 或任意一门语言中的系统 API 来工作，能简单为他们自己增加 -自定义设置，PHP 和 Python 是学起来很简单的，并且比起曾经的图形界面更加的灵活，为什么还要操心其他事呢？ +但这种简单的实现却远远不能体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它数据库的 Schema 没有多大关系 - 实际上在有幸研读过 Stackoverflow 的源码之后，我得以印证了自己的想法，Stackoverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后各种精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的很少会去考虑到产品背后的打磨和雕琢工作，因为他们认为这些打磨和雕琢都是偶然的，甚至是无足轻重的。 -同样的，节制和管理界面可以被削减。如果你是一个管理员，你可以进入 SQL 服务器，所以你可以做任何真正的管理-就像这样，管理员可以通过任何的 Django -管理和类似的系统给你提供支持，因为，毕竟只有少数用户是 mods，mods 应该理解网站是怎么运作、停止的。当然，没有 Stack Overflow 的接口失败会被纠正 -，即使 Stack Overflow 的愚蠢的要求，你必须知道如何去使用 openID （它是最糟糕的缺点）最后得到修复。我确信任何的开源的克隆都会狂热地跟随它- -即使 GNOME 和 KDE 多年来亦步亦趋地复制 windows ，而不是尝试去修复它自己最明显的缺陷。 +这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 Stack Overflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遇到种种关键和核心的问题，让他们阴沟翻船，半途而废。拿 Badge （徽章功能）来说，如果你要针对普通终端用户来设计 Badge , 则要么需要实现一个用户可用来个性化设置 bagdge 的 GUI，要么则取巧的设计出一个比较通用的 Badge 供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给 Badge 这种东西设计一个功能全面的 GUI 是根本不肯能的。而且他们会固执地把任何标准 badge 的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 正在使用的流程和方案：即实现一个通用的机制, 以便那些可以自如使用基于 Python 或 Php 或其他语言的 的系统API的人可以轻松的定制化他们自己的 Badge。而且老实说，PHP 和 Python 比任何可能的 GUI 接口要 好用和强大得多，谁还会考虑 GUI 的方案呢？（出自开源开发者的想法） -开发者可能不会关心应用的这些部分，但是最终用户会，当他们尝试去决定使用哪个应用时会去考虑这些。就好像一家好的软件公司希望通过确保其产品在出货之前 -是一流的来降低其支持成本一样，所以，同样的，懂行的消费者想在他们购买这些产品之前确保产品好用，以便他们不需要去寻求帮助，开源产品就失败在这种地方 -，一般来说，专有解决方案会做得更好。 +同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何mod的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计 - 即要求用户必须拥有一个 OpenID 并知道如何使用它 - 在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的确是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。 -这不是说开源软件没有他们自己的立足之地，这个博客运行在 Apache，Django，PostgreSQL 和 Linux 上。但是让我告诉你，配置这些堆栈不是为了让人心灰意懒 -，PostgreSQL 需要在老版本上移除设置。然后，在 Ubuntu 和 FreeBSD 最新的版本上，仍然要求用户搭建第一个数据库集群，MS SQL不需要这些东西，Apache... -天啊，甚至没有让我开始尝试去向一个初学者用户解释如何去得到虚拟机，MovableType，一对 Django 应用程序，而且所有的 WordPress 都可以在一个单一的安装下 -顺利运行，像在地狱一样，只是试图解释 Apache 的分叉线程变换给技术上精明的非开发人员就是一个噩梦，IIS 7 和操作系统的 Apache 服务器是非常闭源的， -图形界面管理程序配置这些这些相同的堆栈非常的简单，Django 是一个伟大的产品，但是它只是基础架构而已，我认为开源软件做的很好，恰恰是因为推动开发者去 -贡献的动机 -下次你看见一个你喜欢的应用，认为所有面向用户的细节非常长和辛苦，就会去让它用起来更令人开心，在谴责你如何能普通的实现整个的可恶的事在一个周末， -十分之九之后，当你认为一个应用的实现简单地简直可笑，你就完全的错失了故事另一边的用户 +开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低之后的售后维护支持成本一样，懂行的消费者也会想要在他们购买这些产品之前就确保产品好用，以便他们不需要在使用的时候不知所措，然后去打电话给售后服务来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。 + +这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache，Django，PostgreSQL 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而且即使是最新版本的 ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。 +相比之下，MS SQL (微软的 SQL) 则不需要你手工配置以上的任何一样东西。至于 Apache ... 我的天，Apache 简直复杂到让我根本来不及尝试给哪个新的用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机，MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也只是一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项正是在这种基础构架的开发和创新上，这也是驱使开发者贡献开源的最本真的动力。 + + +所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的再一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。 via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/ -作者：Benjamin Pollack 译者：hopefully2333 校对：校对者ID +作者：Benjamin Pollack 译者：hopefully2333 校对：yunfengHe 本文由 LCTT 原创编译，Linux中国 荣誉推出 From 7e914e66ebbaac55ead581a5a9d4878680df6cf5 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Fri, 15 Dec 2017 00:19:22 +0800 Subject: [PATCH 08/16] v1 --- ...The One in Which I Call Out Hacker News.md | 67 +++++++++++++++++++ ...The One in Which I Call Out Hacker News.md | 6 +- 2 files changed, 72 insertions(+), 1 deletion(-) create mode 100644 20090701 The One in Which I Call Out Hacker News.md diff --git a/20090701 The One in Which I Call Out Hacker News.md b/20090701 The One in Which I Call Out Hacker News.md new file mode 100644 index 0000000000..30e796cb8a --- /dev/null +++ b/20090701 The One in Which I Call Out Hacker News.md @@ -0,0 +1,67 @@ +因为这个，我找 Hacker News 期刊理论了一番 + +实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ +不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员永远的乐观主义。 +- 出自 Owen Astrachan 教授于 2004 年 2 月 23 日在 CPS 108 上的讲座 + +指责开源软件总是离奇难用已经不是一个新论点了。这样的论点之前就被很多比我更为雄辩的人提及过，甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？ + +在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为编写代码实现一个StackOverflow可以简单到搞笑的程度，并自信的声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品就已经是一个很好的例证了。 + +秉承着自由讨论的精神，我们来假设一个场景。你在思考之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词(也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少80个小时的时间。 + +或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭源 StackOverflow 代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄源 StackOverflow 代码用时的十倍时间来让我自己写 StackOverflow, 我可是打死也做不到。 + +好的，我知道你在听到这些假设的时候已经开始觉得泄气了。*你在想，如果不是全部实现，而只是实现 StackOverflow 大部分的功能呢？这总归会容易很多了吧* + +好的，问题是什么是大部分功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题和其答案的投票系统来显示大家对某个答案是赞同还是反对。只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且 +与 Markdown 接合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的那个超棒的编辑器 ）。你还需要为所有控件购买或者设计一些小图标小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。 + +但是如果你实现了以上所有功能，可以说你就已经把要做的都做完了。 + +除非...除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现回答的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移冷却下去沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登陆事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和徽章（Badge）。你需要去显示用户的 Karma 历史，点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 slashdot，reddit 或是 StackOverflow 这些动作影响到。 + +在这之后！你会以为你基本已经大功告成了！ + +...为了产品的完整性，在上面所述的工作都完成之后，你又奋不顾身的去实现了升级功能，界面语言的国际化，Karma 值上限，以及让网站更专业的CSS设计，AJAX，还有那些看起来理所当然做起来却让人吐血的功能和特性。如果你不是真的动手来尝试做一个和 StackOverflow 一摸一样的系统，你肯定不会意识到在整个程序设计实施的过程中，你会踩到无数的鬼才会知道的大坑。 + +那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？ + +正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也正是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。因为看似简单的功能，做起来却总是布满荆棘。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码 + + +create table QUESTION (ID identity primary key, + TITLE varchar(255), --- 为什么我知道你认为是 255 + BODY text, + UPVOTES integer not null default 0, + DOWNVOTES integer not null default 0, + USER integer references USER(ID)); +create table RESPONSE (ID identity primary key, + BODY text, + UPVOTES integer not null default 0, + DOWNVOTES integer not null default 0, + QUESTION integer references QUESTION(ID)) + + +如果你让这些开发者去实现 Stack Overflow，进入他脑海中的就是上面的两个SQL表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登陆和注销功能，评论功能，投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登陆和评论的功能。 + +但这种简单的实现却远远不能体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它数据库的 Schema 没有多大关系 - 实际上在有幸研读过 Stackoverflow 的源码之后，我得以印证了自己的想法，Stackoverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后各种精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的很少会去考虑到产品背后的打磨和雕琢工作，因为他们认为这些打磨和雕琢都是偶然的，甚至是无足轻重的。 + +这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 Stack Overflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遇到种种关键和核心的问题，让他们阴沟翻船，半途而废。拿 Badge （徽章功能）来说，如果你要针对普通终端用户来设计 Badge , 则要么需要实现一个用户可用来个性化设置 bagdge 的 GUI，要么则取巧的设计出一个比较通用的 Badge 供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给 Badge 这种东西设计一个功能全面的 GUI 是根本不肯能的。而且他们会固执地把任何标准 badge 的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 正在使用的流程和方案：即实现一个通用的机制, 以便那些可以自如使用基于 Python 或 Php 或其他语言的 的系统API的人可以轻松的定制化他们自己的 Badge。而且老实说，PHP 和 Python 比任何可能的 GUI 接口要 好用和强大得多，谁还会考虑 GUI 的方案呢？（出自开源开发者的想法） + +同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何mod的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计 - 即要求用户必须拥有一个 OpenID 并知道如何使用它 - 在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的确是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。 + + +开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低之后的售后维护支持成本一样，懂行的消费者也会想要在他们购买这些产品之前就确保产品好用，以便他们不需要在使用的时候不知所措，然后去打电话给售后服务来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。 + +这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache，Django，PostgreSQL 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而且即使是最新版本的 ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。 +相比之下，MS SQL (微软的 SQL) 则不需要你手工配置以上的任何一样东西。至于 Apache ... 我的天，Apache 简直复杂到让我根本来不及尝试给哪个新的用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机，MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也只是一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项正是在这种基础构架的开发和创新上，这也是驱使开发者贡献开源的最本真的动力。 + + +所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的再一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。 + +via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/ + +作者：Benjamin Pollack 译者：hopefully2333 校对：yunfengHe + +本文由 LCTT 原创编译，Linux中国 荣誉推出 diff --git a/translated/tech/20090701 The One in Which I Call Out Hacker News.md b/translated/tech/20090701 The One in Which I Call Out Hacker News.md index 30e796cb8a..e4008b8256 100644 --- a/translated/tech/20090701 The One in Which I Call Out Hacker News.md +++ b/translated/tech/20090701 The One in Which I Call Out Hacker News.md @@ -1,4 +1,5 @@ 因为这个，我找 Hacker News 期刊理论了一番 +============================================================ 实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ 不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员永远的乐观主义。 @@ -29,7 +30,7 @@ 正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也正是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。因为看似简单的功能，做起来却总是布满荆棘。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码 - +```SQL create table QUESTION (ID identity primary key, TITLE varchar(255), --- 为什么我知道你认为是 255 BODY text, @@ -42,6 +43,7 @@ create table RESPONSE (ID identity primary key, DOWNVOTES integer not null default 0, QUESTION integer references QUESTION(ID)) +``` 如果你让这些开发者去实现 Stack Overflow，进入他脑海中的就是上面的两个SQL表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登陆和注销功能，评论功能，投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登陆和评论的功能。 @@ -60,6 +62,8 @@ create table RESPONSE (ID identity primary key, 所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的再一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。 +------------------------------------------------------------------------------- + via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/ 作者：Benjamin Pollack 译者：hopefully2333 校对：yunfengHe From d208c6274a8459ecb33853c7ab609877cea07f63 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Fri, 15 Dec 2017 00:24:36 +0800 Subject: [PATCH 09/16] v2 --- .../tech/20090701 The One in Which I Call Out Hacker News.md | 2 +- .../tech/20171120 Containers and Kubernetes Whats next.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/translated/tech/20090701 The One in Which I Call Out Hacker News.md b/translated/tech/20090701 The One in Which I Call Out Hacker News.md index e4008b8256..f0e58889eb 100644 --- a/translated/tech/20090701 The One in Which I Call Out Hacker News.md +++ b/translated/tech/20090701 The One in Which I Call Out Hacker News.md @@ -1,7 +1,7 @@ 因为这个，我找 Hacker News 期刊理论了一番 ============================================================ -实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ +> 实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ 不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员永远的乐观主义。 - 出自 Owen Astrachan 教授于 2004 年 2 月 23 日在 CPS 108 上的讲座 diff --git a/translated/tech/20171120 Containers and Kubernetes Whats next.md b/translated/tech/20171120 Containers and Kubernetes Whats next.md index 5ed099c170..759887dbd2 100644 --- a/translated/tech/20171120 Containers and Kubernetes Whats next.md +++ b/translated/tech/20171120 Containers and Kubernetes Whats next.md @@ -1,6 +1,6 @@ 容器技术和 k8s 的下一站： ============================================================ -### 想知道容器编排管理和 K8s 的最新展望么？来看看专家怎么说。 +### 想知道容器编排管理和 K8s 的最新展望么？来看看专家怎么说。 ![CIO_Big Data Decisions_2](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO_Big%20Data%20Decisions_2.png?itok=Y5zMHxf8 "CIO_Big Data Decisions_2") From 8c657393d102f174bc39c896c17ada913c49ea82 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Fri, 15 Dec 2017 00:38:32 +0800 Subject: [PATCH 10/16] =?UTF-8?q?=E6=A0=A1=E5=AF=B9=E7=89=88=E6=9C=ACv3=20?= =?UTF-8?q?Yunfeng=20He?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...01 The One in Which I Call Out Hacker News.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/translated/tech/20090701 The One in Which I Call Out Hacker News.md b/translated/tech/20090701 The One in Which I Call Out Hacker News.md index f0e58889eb..da55b85e6a 100644 --- a/translated/tech/20090701 The One in Which I Call Out Hacker News.md +++ b/translated/tech/20090701 The One in Which I Call Out Hacker News.md @@ -7,24 +7,24 @@ 指责开源软件总是离奇难用已经不是一个新论点了。这样的论点之前就被很多比我更为雄辩的人提及过，甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？ -在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为编写代码实现一个StackOverflow可以简单到搞笑的程度，并自信的声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品就已经是一个很好的例证了。 +在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为编写代码实现一个 StackOverflow 可以简单到搞笑的程度，并自信的声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品就已经是一个很好的例证了。 -秉承着自由讨论的精神，我们来假设一个场景。你在思考之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词(也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少80个小时的时间。 +秉承着自由讨论的精神，我们来假设一个场景。你在思考之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词 (也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。 或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭源 StackOverflow 代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄源 StackOverflow 代码用时的十倍时间来让我自己写 StackOverflow, 我可是打死也做不到。 -好的，我知道你在听到这些假设的时候已经开始觉得泄气了。*你在想，如果不是全部实现，而只是实现 StackOverflow 大部分的功能呢？这总归会容易很多了吧* +好的，我知道你在听到这些假设的时候已经开始觉得泄气了。你在想，如果不是全部实现，而只是实现 StackOverflow 大部分的功能呢？这总归会容易很多了吧。 好的，问题是什么是大部分功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题和其答案的投票系统来显示大家对某个答案是赞同还是反对。只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且 与 Markdown 接合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的那个超棒的编辑器 ）。你还需要为所有控件购买或者设计一些小图标小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。 但是如果你实现了以上所有功能，可以说你就已经把要做的都做完了。 -除非...除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现回答的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移冷却下去沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登陆事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和徽章（Badge）。你需要去显示用户的 Karma 历史，点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 slashdot，reddit 或是 StackOverflow 这些动作影响到。 +除非...除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现回答的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移冷却下去沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登陆事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和徽章（Badge）。你需要去显示用户的 Karma 历史，点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 Slashdot，Reddit 或是 StackOverflow 这些动作影响到。 在这之后！你会以为你基本已经大功告成了！ -...为了产品的完整性，在上面所述的工作都完成之后，你又奋不顾身的去实现了升级功能，界面语言的国际化，Karma 值上限，以及让网站更专业的CSS设计，AJAX，还有那些看起来理所当然做起来却让人吐血的功能和特性。如果你不是真的动手来尝试做一个和 StackOverflow 一摸一样的系统，你肯定不会意识到在整个程序设计实施的过程中，你会踩到无数的鬼才会知道的大坑。 +...为了产品的完整性，在上面所述的工作都完成之后，你又奋不顾身的去实现了升级功能，界面语言的国际化，Karma 值上限，以及让网站更专业的 CSS 设计，AJAX，还有那些看起来理所当然做起来却让人吐血的功能和特性。如果你不是真的动手来尝试做一个和 StackOverflow 一摸一样的系统，你肯定不会意识到在整个程序设计实施的过程中，你会踩到无数的鬼才会知道的大坑。 那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？ @@ -45,11 +45,11 @@ create table RESPONSE (ID identity primary key, ``` -如果你让这些开发者去实现 Stack Overflow，进入他脑海中的就是上面的两个SQL表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登陆和注销功能，评论功能，投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登陆和评论的功能。 +如果你让这些开发者去实现 StackOverflow，进入他脑海中的就是上面的两个 SQL 表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登陆和注销功能，评论功能，投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登陆和评论的功能。 -但这种简单的实现却远远不能体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它数据库的 Schema 没有多大关系 - 实际上在有幸研读过 Stackoverflow 的源码之后，我得以印证了自己的想法，Stackoverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后各种精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的很少会去考虑到产品背后的打磨和雕琢工作，因为他们认为这些打磨和雕琢都是偶然的，甚至是无足轻重的。 +但这种简单的实现却远远不能体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它数据库的 Schema 没有多大关系 - 实际上在有幸研读过 StackOverflow 的源码之后，我得以印证了自己的想法，StackOverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后各种精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的很少会去考虑到产品背后的打磨和雕琢工作，因为他们认为这些打磨和雕琢都是偶然的，甚至是无足轻重的。 -这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 Stack Overflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遇到种种关键和核心的问题，让他们阴沟翻船，半途而废。拿 Badge （徽章功能）来说，如果你要针对普通终端用户来设计 Badge , 则要么需要实现一个用户可用来个性化设置 bagdge 的 GUI，要么则取巧的设计出一个比较通用的 Badge 供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给 Badge 这种东西设计一个功能全面的 GUI 是根本不肯能的。而且他们会固执地把任何标准 badge 的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 正在使用的流程和方案：即实现一个通用的机制, 以便那些可以自如使用基于 Python 或 Php 或其他语言的 的系统API的人可以轻松的定制化他们自己的 Badge。而且老实说，PHP 和 Python 比任何可能的 GUI 接口要 好用和强大得多，谁还会考虑 GUI 的方案呢？（出自开源开发者的想法） +这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 StackOverflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遇到种种关键和核心的问题，让他们阴沟翻船，半途而废。拿 Badge （徽章功能）来说，如果你要针对普通终端用户来设计 Badge , 则要么需要实现一个用户可用来个性化设置 bagdge 的 GUI，要么则取巧的设计出一个比较通用的 Badge 供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给 Badge 这种东西设计一个功能全面的 GUI 是根本不肯能的。而且他们会固执地把任何标准 badge 的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 正在使用的流程和方案：即实现一个通用的机制, 以便那些可以自如使用基于 Python 或 Php 或其他语言的 的系统API的人可以轻松的定制化他们自己的 Badge。而且老实说，PHP 和 Python 比任何可能的 GUI 接口要 好用和强大得多，谁还会考虑 GUI 的方案呢？（出自开源开发者的想法） 同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何mod的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计 - 即要求用户必须拥有一个 OpenID 并知道如何使用它 - 在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的确是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。 From 4cfbabdfb1e79e9e6bc23fe6896b2b8b692da084 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Fri, 15 Dec 2017 00:45:39 +0800 Subject: [PATCH 11/16] =?UTF-8?q?v4=20=E5=B7=B2=E6=A0=A1=E5=AF=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../tech/20090701 The One in Which I Call Out Hacker News.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/translated/tech/20090701 The One in Which I Call Out Hacker News.md b/translated/tech/20090701 The One in Which I Call Out Hacker News.md index da55b85e6a..f47f475363 100644 --- a/translated/tech/20090701 The One in Which I Call Out Hacker News.md +++ b/translated/tech/20090701 The One in Which I Call Out Hacker News.md @@ -7,7 +7,7 @@ 指责开源软件总是离奇难用已经不是一个新论点了。这样的论点之前就被很多比我更为雄辩的人提及过，甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？ -在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为编写代码实现一个 StackOverflow 可以简单到搞笑的程度，并自信的声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品就已经是一个很好的例证了。 +在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为编写代码实现和一个和 StackOverflow 一样的系统可以简单到搞笑的程度，并自信的声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品就已经是一个很好的例证了。 秉承着自由讨论的精神，我们来假设一个场景。你在思考之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词 (也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。 @@ -28,7 +28,7 @@ 那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？ -正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也正是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。因为看似简单的功能，做起来却总是布满荆棘。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码 +正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也同样是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。因为看似简单的功能，做起来却总是布满荆棘。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码 ```SQL create table QUESTION (ID identity primary key, From d9b3a67c138a65e1a4db119660ce256f4e75f62d Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Fri, 15 Dec 2017 02:04:19 +0800 Subject: [PATCH 12/16] v5 --- ...The One in Which I Call Out Hacker News.md | 24 +++++++++---------- 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/translated/tech/20090701 The One in Which I Call Out Hacker News.md b/translated/tech/20090701 The One in Which I Call Out Hacker News.md index f47f475363..f2b06ae23a 100644 --- a/translated/tech/20090701 The One in Which I Call Out Hacker News.md +++ b/translated/tech/20090701 The One in Which I Call Out Hacker News.md @@ -2,25 +2,25 @@ ============================================================ > 实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ -不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员永远的乐观主义。 +不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员单方面的乐观主义。 - 出自 Owen Astrachan 教授于 2004 年 2 月 23 日在 CPS 108 上的讲座 指责开源软件总是离奇难用已经不是一个新论点了。这样的论点之前就被很多比我更为雄辩的人提及过，甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？ -在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为编写代码实现和一个和 StackOverflow 一样的系统可以简单到搞笑的程度，并自信的声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品就已经是一个很好的例证了。 +在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为编写代码实现和一个和 StackOverflow 一样的系统可以简单到爆，并自信的声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品就已经是一个很好的例证了。 -秉承着自由讨论的精神，我们来假设一个场景。你在思考之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词 (也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。 +秉承着自由讨论的精神，我们来假设一个场景。你在思考了一阵之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词 (也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。 -或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭源 StackOverflow 代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄源 StackOverflow 代码用时的十倍时间来让我自己写 StackOverflow, 我可是打死也做不到。 +或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭 StackOverflow 源代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄源 StackOverflow 代码用时的十倍时间来让我自己写 StackOverflow, 我可是打死也做不到。 好的，我知道你在听到这些假设的时候已经开始觉得泄气了。你在想，如果不是全部实现，而只是实现 StackOverflow 大部分的功能呢？这总归会容易很多了吧。 -好的，问题是什么是大部分功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题和其答案的投票系统来显示大家对某个答案是赞同还是反对。只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且 +好的，问题是什么是大部分功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题和其答案的投票系统，来显示大家对某个答案是赞同还是反对。因为只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且 与 Markdown 接合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的那个超棒的编辑器 ）。你还需要为所有控件购买或者设计一些小图标小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。 但是如果你实现了以上所有功能，可以说你就已经把要做的都做完了。 -除非...除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现回答的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移冷却下去沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登陆事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和徽章（Badge）。你需要去显示用户的 Karma 历史，点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 Slashdot，Reddit 或是 StackOverflow 这些动作影响到。 +除非...除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现对问题答案的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登陆事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和徽章（Badge）。你需要去显示用户的 Karma 历史，以及他们的历史点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 Slashdot，Reddit 或是 StackOverflow 这些动作影响到。 在这之后！你会以为你基本已经大功告成了！ @@ -28,7 +28,7 @@ 那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？ -正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也同样是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。因为看似简单的功能，做起来却总是布满荆棘。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码 +正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也同样是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码 ```SQL create table QUESTION (ID identity primary key, @@ -49,15 +49,15 @@ create table RESPONSE (ID identity primary key, 但这种简单的实现却远远不能体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它数据库的 Schema 没有多大关系 - 实际上在有幸研读过 StackOverflow 的源码之后，我得以印证了自己的想法，StackOverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后各种精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的很少会去考虑到产品背后的打磨和雕琢工作，因为他们认为这些打磨和雕琢都是偶然的，甚至是无足轻重的。 -这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 StackOverflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遇到种种关键和核心的问题，让他们阴沟翻船，半途而废。拿 Badge （徽章功能）来说，如果你要针对普通终端用户来设计 Badge , 则要么需要实现一个用户可用来个性化设置 bagdge 的 GUI，要么则取巧的设计出一个比较通用的 Badge 供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给 Badge 这种东西设计一个功能全面的 GUI 是根本不肯能的。而且他们会固执地把任何标准 badge 的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 正在使用的流程和方案：即实现一个通用的机制, 以便那些可以自如使用基于 Python 或 Php 或其他语言的 的系统API的人可以轻松的定制化他们自己的 Badge。而且老实说，PHP 和 Python 比任何可能的 GUI 接口要 好用和强大得多，谁还会考虑 GUI 的方案呢？（出自开源开发者的想法） +这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 StackOverflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遭遇种种关键和核心的问题，让他们阴沟翻船，半途而废。拿 Badge （徽章功能）来说，如果你要针对普通终端用户来设计 Badge , 则要么需要实现一个用户可用来个性化设置 bagdge 的 GUI，要么则取巧的设计出一个比较通用的 Badge 供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给 Badge 这种东西设计一个功能全面的 GUI 是根本不肯能的。而且他们会固执地把任何标准 badge 的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 程序都在使用的流程和方案：即实现一个通用的机制, 提供以 Python 或 Php 为基础的一些系统API， 以便那些可以自如使用 Python 或 Php 的人可以轻松的通过这些编程接口来定制化他们自己的 Badge。而且老实说，PHP 和 Python 可是比任何可能的 GUI 接口都要好用和强大得多，为什么还要考虑 GUI 的方案呢？（出自开源开发者的想法） -同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何mod的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计 - 即要求用户必须拥有一个 OpenID 并知道如何使用它 - 在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的确是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。 +同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何mod的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计（即要求用户必须拥有一个 OpenID 并知道如何使用它）在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的确是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。 -开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低之后的售后维护支持成本一样，懂行的消费者也会想要在他们购买这些产品之前就确保产品好用，以便他们不需要在使用的时候不知所措，然后去打电话给售后服务来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。 +开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低售后维护支持的成本一样，懂行的消费者也会在他们购买这些产品之前就确保产品好用，以防在使用的时候不知所措，然后无奈的打电话给售后来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。 -这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache，Django，PostgreSQL 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而且即使是最新版本的 ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。 -相比之下，MS SQL (微软的 SQL) 则不需要你手工配置以上的任何一样东西。至于 Apache ... 我的天，Apache 简直复杂到让我根本来不及尝试给哪个新的用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机，MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也只是一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项正是在这种基础构架的开发和创新上，这也是驱使开发者贡献开源的最本真的动力。 +这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache，Django，PostgreSQL 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而即使是最新版本的 ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。 +相比之下，MS SQL (微软的 SQL) 则不需要你手工配置以上的任何一样东西。至于 Apache ... 我的天，Apache 简直复杂到让我根本来不及去尝试给一个新用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机，MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也只是一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项就恰恰在这种基础构架的开发和创新上，这也正是驱使开发者为开源做贡献的最本真的动力。 所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的再一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。 From fff734bf77cc3e0793ce4a4caa819ab561ab006d Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Fri, 15 Dec 2017 20:08:03 +0800 Subject: [PATCH 13/16] =?UTF-8?q?=E6=A0=A1=E5=AF=B9=E5=AE=8C=E6=AF=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...The One in Which I Call Out Hacker News.md | 67 ------------------- ...The One in Which I Call Out Hacker News.md | 58 ++++++++++------ 2 files changed, 38 insertions(+), 87 deletions(-) delete mode 100644 20090701 The One in Which I Call Out Hacker News.md diff --git a/20090701 The One in Which I Call Out Hacker News.md b/20090701 The One in Which I Call Out Hacker News.md deleted file mode 100644 index 30e796cb8a..0000000000 --- a/20090701 The One in Which I Call Out Hacker News.md +++ /dev/null @@ -1,67 +0,0 @@ -因为这个，我找 Hacker News 期刊理论了一番 - -实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ -不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员永远的乐观主义。 -- 出自 Owen Astrachan 教授于 2004 年 2 月 23 日在 CPS 108 上的讲座 - -指责开源软件总是离奇难用已经不是一个新论点了。这样的论点之前就被很多比我更为雄辩的人提及过，甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？ - -在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为编写代码实现一个StackOverflow可以简单到搞笑的程度，并自信的声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品就已经是一个很好的例证了。 - -秉承着自由讨论的精神，我们来假设一个场景。你在思考之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词(也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少80个小时的时间。 - -或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭源 StackOverflow 代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄源 StackOverflow 代码用时的十倍时间来让我自己写 StackOverflow, 我可是打死也做不到。 - -好的，我知道你在听到这些假设的时候已经开始觉得泄气了。*你在想，如果不是全部实现，而只是实现 StackOverflow 大部分的功能呢？这总归会容易很多了吧* - -好的，问题是什么是大部分功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题和其答案的投票系统来显示大家对某个答案是赞同还是反对。只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且 -与 Markdown 接合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的那个超棒的编辑器 ）。你还需要为所有控件购买或者设计一些小图标小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。 - -但是如果你实现了以上所有功能，可以说你就已经把要做的都做完了。 - -除非...除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现回答的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移冷却下去沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登陆事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和徽章（Badge）。你需要去显示用户的 Karma 历史，点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 slashdot，reddit 或是 StackOverflow 这些动作影响到。 - -在这之后！你会以为你基本已经大功告成了！ - -...为了产品的完整性，在上面所述的工作都完成之后，你又奋不顾身的去实现了升级功能，界面语言的国际化，Karma 值上限，以及让网站更专业的CSS设计，AJAX，还有那些看起来理所当然做起来却让人吐血的功能和特性。如果你不是真的动手来尝试做一个和 StackOverflow 一摸一样的系统，你肯定不会意识到在整个程序设计实施的过程中，你会踩到无数的鬼才会知道的大坑。 - -那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？ - -正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也正是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。因为看似简单的功能，做起来却总是布满荆棘。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码 - - -create table QUESTION (ID identity primary key, - TITLE varchar(255), --- 为什么我知道你认为是 255 - BODY text, - UPVOTES integer not null default 0, - DOWNVOTES integer not null default 0, - USER integer references USER(ID)); -create table RESPONSE (ID identity primary key, - BODY text, - UPVOTES integer not null default 0, - DOWNVOTES integer not null default 0, - QUESTION integer references QUESTION(ID)) - - -如果你让这些开发者去实现 Stack Overflow，进入他脑海中的就是上面的两个SQL表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登陆和注销功能，评论功能，投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登陆和评论的功能。 - -但这种简单的实现却远远不能体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它数据库的 Schema 没有多大关系 - 实际上在有幸研读过 Stackoverflow 的源码之后，我得以印证了自己的想法，Stackoverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后各种精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的很少会去考虑到产品背后的打磨和雕琢工作，因为他们认为这些打磨和雕琢都是偶然的，甚至是无足轻重的。 - -这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 Stack Overflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遇到种种关键和核心的问题，让他们阴沟翻船，半途而废。拿 Badge （徽章功能）来说，如果你要针对普通终端用户来设计 Badge , 则要么需要实现一个用户可用来个性化设置 bagdge 的 GUI，要么则取巧的设计出一个比较通用的 Badge 供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给 Badge 这种东西设计一个功能全面的 GUI 是根本不肯能的。而且他们会固执地把任何标准 badge 的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 正在使用的流程和方案：即实现一个通用的机制, 以便那些可以自如使用基于 Python 或 Php 或其他语言的 的系统API的人可以轻松的定制化他们自己的 Badge。而且老实说，PHP 和 Python 比任何可能的 GUI 接口要 好用和强大得多，谁还会考虑 GUI 的方案呢？（出自开源开发者的想法） - -同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何mod的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计 - 即要求用户必须拥有一个 OpenID 并知道如何使用它 - 在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的确是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。 - - -开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低之后的售后维护支持成本一样，懂行的消费者也会想要在他们购买这些产品之前就确保产品好用，以便他们不需要在使用的时候不知所措，然后去打电话给售后服务来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。 - -这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache，Django，PostgreSQL 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而且即使是最新版本的 ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。 -相比之下，MS SQL (微软的 SQL) 则不需要你手工配置以上的任何一样东西。至于 Apache ... 我的天，Apache 简直复杂到让我根本来不及尝试给哪个新的用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机，MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也只是一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项正是在这种基础构架的开发和创新上，这也是驱使开发者贡献开源的最本真的动力。 - - -所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的再一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。 - -via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/ - -作者：Benjamin Pollack 译者：hopefully2333 校对：yunfengHe - -本文由 LCTT 原创编译，Linux中国 荣誉推出 diff --git a/translated/tech/20090701 The One in Which I Call Out Hacker News.md b/translated/tech/20090701 The One in Which I Call Out Hacker News.md index f2b06ae23a..67b4c2ea96 100644 --- a/translated/tech/20090701 The One in Which I Call Out Hacker News.md +++ b/translated/tech/20090701 The One in Which I Call Out Hacker News.md @@ -1,24 +1,25 @@ -因为这个，我找 Hacker News 期刊理论了一番 -============================================================ +# [因为这个，我找 Hacker News 期刊理论了一番][14] -> 实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ -不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员单方面的乐观主义。 -- 出自 Owen Astrachan 教授于 2004 年 2 月 23 日在 CPS 108 上的讲座 -指责开源软件总是离奇难用已经不是一个新论点了。这样的论点之前就被很多比我更为雄辩的人提及过，甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？ +> “实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ +不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员单方面的乐观主义。” +> +> — 出自 [Owen Astrachan][1] 教授于 2004 年 2 月 23 日在 [CPS 108][2] 上的讲座 -在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为编写代码实现和一个和 StackOverflow 一样的系统可以简单到爆，并自信的声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序，以此来证明这一切是多么容易。另一些人则插话说，现有的那些仿制产品就已经是一个很好的例证了。 +[指责开源软件总是离奇难用已经不是一个新论点了][5]; 这样的论点之前就被很多比我更为雄辩的人提及过, 甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？ -秉承着自由讨论的精神，我们来假设一个场景。你在思考了一阵之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词 (也就是大约每秒敲八个字母)，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。 +在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为 [编写代码实现和一个跟 StackOverflow 一样的系统可以简单到爆][6]，并自信的 [声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序][7]，以此来证明这一切是多么容易。另一些人则插话说，[现有的][8][那些仿制产品][9] 就已经是一个很好的例证了。 + +秉承着自由讨论的精神，我们来假设一个场景。你在思考了一阵之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词 ([也就是大约每秒敲八个字母][10])，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。 或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭 StackOverflow 源代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄源 StackOverflow 代码用时的十倍时间来让我自己写 StackOverflow, 我可是打死也做不到。 -好的，我知道你在听到这些假设的时候已经开始觉得泄气了。你在想，如果不是全部实现，而只是实现 StackOverflow 大部分的功能呢？这总归会容易很多了吧。 +_好的_，我知道你在听到这些假设的时候已经开始觉得泄气了。*你在想，如果不是全部实现，而只是实现 StackOverflow **大部分** 的功能呢？这总归会容易很多了吧。* -好的，问题是什么是大部分功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题和其答案的投票系统，来显示大家对某个答案是赞同还是反对。因为只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且 -与 Markdown 接合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的那个超棒的编辑器 ）。你还需要为所有控件购买或者设计一些小图标小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。 +好的，问题是什么是 "大部分" 功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题和其答案的投票系统，来显示大家对某个答案是赞同还是反对。因为只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且 +与 Markdown 接合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的 [那个超棒的编辑器][11] ）。你还需要为所有控件购买或者设计一些小图标小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。 -但是如果你实现了以上所有功能，可以说你就已经把要做的都做完了。 +但是如果你实现了以上_所有_功能，可以说你_就已经_把要做的都做完了。 除非...除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现对问题答案的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登陆事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和徽章（Badge）。你需要去显示用户的 Karma 历史，以及他们的历史点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 Slashdot，Reddit 或是 StackOverflow 这些动作影响到。 @@ -28,9 +29,9 @@ 那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？ -正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也同样是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码 +正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也同样是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码: -```SQL +``` create table QUESTION (ID identity primary key, TITLE varchar(255), --- 为什么我知道你认为是 255 BODY text, @@ -42,12 +43,11 @@ create table RESPONSE (ID identity primary key, UPVOTES integer not null default 0, DOWNVOTES integer not null default 0, QUESTION integer references QUESTION(ID)) - ``` 如果你让这些开发者去实现 StackOverflow，进入他脑海中的就是上面的两个 SQL 表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登陆和注销功能，评论功能，投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登陆和评论的功能。 -但这种简单的实现却远远不能体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它数据库的 Schema 没有多大关系 - 实际上在有幸研读过 StackOverflow 的源码之后，我得以印证了自己的想法，StackOverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后各种精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的很少会去考虑到产品背后的打磨和雕琢工作，因为他们认为这些打磨和雕琢都是偶然的，甚至是无足轻重的。 +但这种简单的实现却_远远不能_体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它数据库的 Schema 没有多大关系 - 实际上在有幸研读过 StackOverflow 的源码之后，我得以印证了自己的想法，StackOverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后_大量的_精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的_很少会去考虑到产品背后的打磨和雕琢工作_，因为他们认为_这些打磨和雕琢都是偶然的，甚至是无足轻重的。_ 这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 StackOverflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遭遇种种关键和核心的问题，让他们阴沟翻船，半途而废。拿 Badge （徽章功能）来说，如果你要针对普通终端用户来设计 Badge , 则要么需要实现一个用户可用来个性化设置 bagdge 的 GUI，要么则取巧的设计出一个比较通用的 Badge 供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给 Badge 这种东西设计一个功能全面的 GUI 是根本不肯能的。而且他们会固执地把任何标准 badge 的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 程序都在使用的流程和方案：即实现一个通用的机制, 提供以 Python 或 Php 为基础的一些系统API， 以便那些可以自如使用 Python 或 Php 的人可以轻松的通过这些编程接口来定制化他们自己的 Badge。而且老实说，PHP 和 Python 可是比任何可能的 GUI 接口都要好用和强大得多，为什么还要考虑 GUI 的方案呢？（出自开源开发者的想法） @@ -56,8 +56,8 @@ create table RESPONSE (ID identity primary key, 开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低售后维护支持的成本一样，懂行的消费者也会在他们购买这些产品之前就确保产品好用，以防在使用的时候不知所措，然后无奈的打电话给售后来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。 -这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache，Django，PostgreSQL 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而即使是最新版本的 ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。 -相比之下，MS SQL (微软的 SQL) 则不需要你手工配置以上的任何一样东西。至于 Apache ... 我的天，Apache 简直复杂到让我根本来不及去尝试给一个新用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机，MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也只是一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项就恰恰在这种基础构架的开发和创新上，这也正是驱使开发者为开源做贡献的最本真的动力。 +这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache，[Django][12]，[PostgreSQL][13] 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而即使是最新版本的 ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。 +相比之下，MS SQL (微软的 SQL) 则不需要你手工配置以上的任何一样东西。至于 Apache ... 我的天，Apache 简直复杂到让我根本来不及去尝试给一个新用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机，MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也 _只是_ 一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项就 _恰恰在_ 这种基础构架的开发和创新上，这也正是驱使开发者为开源做贡献的最本真的动力。 所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的再一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。 @@ -66,6 +66,24 @@ create table RESPONSE (ID identity primary key, via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/ -作者：Benjamin Pollack 译者：hopefully2333 校对：yunfengHe +作者：[Benjamin Pollack][a] +译者：[hopefully2333](https://github.com/hopefully2333) +校对：[yunfengHe](https://github.com/yunfengHe) -本文由 LCTT 原创编译，Linux中国 荣誉推出 +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]:https://bitquabit.com/meta/about/ +[1]:http://www.cs.duke.edu/~ola/ +[2]:http://www.cs.duke.edu/courses/cps108/spring04/ +[3]:https://bitquabit.com/categories/programming +[4]:https://bitquabit.com/categories/technology +[5]:http://blog.bitquabit.com/2009/06/30/one-which-i-say-open-source-software-sucks/ +[6]:http://news.ycombinator.com/item?id=678501 +[7]:http://news.ycombinator.com/item?id=678704 +[8]:http://code.google.com/p/cnprog/ +[9]:http://code.google.com/p/soclone/ +[10]:http://en.wikipedia.org/wiki/Words_per_minute +[11]:http://github.com/derobins/wmd/tree/master +[12]:http://www.djangoproject.com/ +[13]:http://www.postgresql.org/ +[14]:https://bitquabit.com/post/one-which-i-call-out-hacker-news/ From a087cb7989836329fe4a0d69e38743d0ec8c84f7 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Fri, 15 Dec 2017 20:13:52 +0800 Subject: [PATCH 14/16] =?UTF-8?q?=E6=9C=80=E7=BB=88=E6=A0=A1=E5=AF=B9?= =?UTF-8?q?=E5=AE=8C=E6=AF=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../tech/20090701 The One in Which I Call Out Hacker News.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/translated/tech/20090701 The One in Which I Call Out Hacker News.md b/translated/tech/20090701 The One in Which I Call Out Hacker News.md index 67b4c2ea96..0b06d3259a 100644 --- a/translated/tech/20090701 The One in Which I Call Out Hacker News.md +++ b/translated/tech/20090701 The One in Which I Call Out Hacker News.md @@ -1,4 +1,4 @@ -# [因为这个，我找 Hacker News 期刊理论了一番][14] +# [因为这个我要点名批评 Hacker News ][14] > “实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ From 73d807724ecbbd9623650bc8d12878cf066550e7 Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Fri, 15 Dec 2017 20:55:04 +0800 Subject: [PATCH 15/16] =?UTF-8?q?Containers=20and=20Kubernetes=20whats=20n?= =?UTF-8?q?ext=20=E7=BF=BB=E8=AF=91=E5=AE=8C=E6=AF=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...The One in Which I Call Out Hacker News.md | 89 ------------------- ...20 Containers and Kubernetes Whats next.md | 2 +- 2 files changed, 1 insertion(+), 90 deletions(-) delete mode 100644 translated/tech/20090701 The One in Which I Call Out Hacker News.md diff --git a/translated/tech/20090701 The One in Which I Call Out Hacker News.md b/translated/tech/20090701 The One in Which I Call Out Hacker News.md deleted file mode 100644 index 0b06d3259a..0000000000 --- a/translated/tech/20090701 The One in Which I Call Out Hacker News.md +++ /dev/null @@ -1,89 +0,0 @@ -# [因为这个我要点名批评 Hacker News ][14] - - -> “实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ -不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员单方面的乐观主义。” -> -> — 出自 [Owen Astrachan][1] 教授于 2004 年 2 月 23 日在 [CPS 108][2] 上的讲座 - -[指责开源软件总是离奇难用已经不是一个新论点了][5]; 这样的论点之前就被很多比我更为雄辩的人提及过, 甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？ - -在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为 [编写代码实现和一个跟 StackOverflow 一样的系统可以简单到爆][6]，并自信的 [声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序][7]，以此来证明这一切是多么容易。另一些人则插话说，[现有的][8][那些仿制产品][9] 就已经是一个很好的例证了。 - -秉承着自由讨论的精神，我们来假设一个场景。你在思考了一阵之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词 ([也就是大约每秒敲八个字母][10])，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。 - -或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭 StackOverflow 源代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄源 StackOverflow 代码用时的十倍时间来让我自己写 StackOverflow, 我可是打死也做不到。 - -_好的_，我知道你在听到这些假设的时候已经开始觉得泄气了。*你在想，如果不是全部实现，而只是实现 StackOverflow **大部分** 的功能呢？这总归会容易很多了吧。* - -好的，问题是什么是 "大部分" 功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题和其答案的投票系统，来显示大家对某个答案是赞同还是反对。因为只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且 -与 Markdown 接合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的 [那个超棒的编辑器][11] ）。你还需要为所有控件购买或者设计一些小图标小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。 - -但是如果你实现了以上_所有_功能，可以说你_就已经_把要做的都做完了。 - -除非...除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现对问题答案的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登陆事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和徽章（Badge）。你需要去显示用户的 Karma 历史，以及他们的历史点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 Slashdot，Reddit 或是 StackOverflow 这些动作影响到。 - -在这之后！你会以为你基本已经大功告成了！ - -...为了产品的完整性，在上面所述的工作都完成之后，你又奋不顾身的去实现了升级功能，界面语言的国际化，Karma 值上限，以及让网站更专业的 CSS 设计，AJAX，还有那些看起来理所当然做起来却让人吐血的功能和特性。如果你不是真的动手来尝试做一个和 StackOverflow 一摸一样的系统，你肯定不会意识到在整个程序设计实施的过程中，你会踩到无数的鬼才会知道的大坑。 - -那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？ - -正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也同样是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码: - -``` -create table QUESTION (ID identity primary key, - TITLE varchar(255), --- 为什么我知道你认为是 255 - BODY text, - UPVOTES integer not null default 0, - DOWNVOTES integer not null default 0, - USER integer references USER(ID)); -create table RESPONSE (ID identity primary key, - BODY text, - UPVOTES integer not null default 0, - DOWNVOTES integer not null default 0, - QUESTION integer references QUESTION(ID)) -``` - -如果你让这些开发者去实现 StackOverflow，进入他脑海中的就是上面的两个 SQL 表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登陆和注销功能，评论功能，投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登陆和评论的功能。 - -但这种简单的实现却_远远不能_体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它数据库的 Schema 没有多大关系 - 实际上在有幸研读过 StackOverflow 的源码之后，我得以印证了自己的想法，StackOverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后_大量的_精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的_很少会去考虑到产品背后的打磨和雕琢工作_，因为他们认为_这些打磨和雕琢都是偶然的，甚至是无足轻重的。_ - -这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 StackOverflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遭遇种种关键和核心的问题，让他们阴沟翻船，半途而废。拿 Badge （徽章功能）来说，如果你要针对普通终端用户来设计 Badge , 则要么需要实现一个用户可用来个性化设置 bagdge 的 GUI，要么则取巧的设计出一个比较通用的 Badge 供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给 Badge 这种东西设计一个功能全面的 GUI 是根本不肯能的。而且他们会固执地把任何标准 badge 的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 程序都在使用的流程和方案：即实现一个通用的机制, 提供以 Python 或 Php 为基础的一些系统API， 以便那些可以自如使用 Python 或 Php 的人可以轻松的通过这些编程接口来定制化他们自己的 Badge。而且老实说，PHP 和 Python 可是比任何可能的 GUI 接口都要好用和强大得多，为什么还要考虑 GUI 的方案呢？（出自开源开发者的想法） - -同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何mod的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计（即要求用户必须拥有一个 OpenID 并知道如何使用它）在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的确是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。 - - -开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低售后维护支持的成本一样，懂行的消费者也会在他们购买这些产品之前就确保产品好用，以防在使用的时候不知所措，然后无奈的打电话给售后来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。 - -这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache，[Django][12]，[PostgreSQL][13] 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而即使是最新版本的 ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。 -相比之下，MS SQL (微软的 SQL) 则不需要你手工配置以上的任何一样东西。至于 Apache ... 我的天，Apache 简直复杂到让我根本来不及去尝试给一个新用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机，MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也 _只是_ 一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项就 _恰恰在_ 这种基础构架的开发和创新上，这也正是驱使开发者为开源做贡献的最本真的动力。 - - -所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的再一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。 - -------------------------------------------------------------------------------- - -via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/ - -作者：[Benjamin Pollack][a] -译者：[hopefully2333](https://github.com/hopefully2333) -校对：[yunfengHe](https://github.com/yunfengHe) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:https://bitquabit.com/meta/about/ -[1]:http://www.cs.duke.edu/~ola/ -[2]:http://www.cs.duke.edu/courses/cps108/spring04/ -[3]:https://bitquabit.com/categories/programming -[4]:https://bitquabit.com/categories/technology -[5]:http://blog.bitquabit.com/2009/06/30/one-which-i-say-open-source-software-sucks/ -[6]:http://news.ycombinator.com/item?id=678501 -[7]:http://news.ycombinator.com/item?id=678704 -[8]:http://code.google.com/p/cnprog/ -[9]:http://code.google.com/p/soclone/ -[10]:http://en.wikipedia.org/wiki/Words_per_minute -[11]:http://github.com/derobins/wmd/tree/master -[12]:http://www.djangoproject.com/ -[13]:http://www.postgresql.org/ -[14]:https://bitquabit.com/post/one-which-i-call-out-hacker-news/ diff --git a/translated/tech/20171120 Containers and Kubernetes Whats next.md b/translated/tech/20171120 Containers and Kubernetes Whats next.md index 759887dbd2..8e414a95dd 100644 --- a/translated/tech/20171120 Containers and Kubernetes Whats next.md +++ b/translated/tech/20171120 Containers and Kubernetes Whats next.md @@ -4,7 +4,7 @@ ![CIO_Big Data Decisions_2](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO_Big%20Data%20Decisions_2.png?itok=Y5zMHxf8 "CIO_Big Data Decisions_2") -如果你想对容器在未来的发展方向有一个整体把握，那么你一定要跟着钱走，看看钱都投在了哪里。当然了，有很多很多的钱正在投入容器的进一步发展。相关研究预计 2020 年容器技术的投入将占有 [27 亿美元][4] 的市场份额 。而在 2016 年，容器相关技术投入的总额为 7.62 亿美元，只有 2020 年投入预计的三分之一。巨额投入的背后是一些显而易见的基本因素，包括容器化的迅速增长以及并行化的大趋势。随着容器被大面积推广和使用，容器编排管理也会被理所当然的推广应用起来。 +如果你想对容器在未来的发展方向有一个整体把握，那么你一定要跟着钱走，看看钱都投在了哪里。当然了，有大量的资金正在投入容器的进一步发展。相关研究预计 2020 年容器技术的投入将占有 [27 亿美元][4] 的市场份额 。而在 2016 年，容器相关技术投入的总额为 7.62 亿美元，只有 2020 年投入预计的三分之一。巨额投入的背后是一些显而易见的基本因素，包括容器化的迅速增长以及并行化的大趋势。随着容器被大面积推广和使用，容器编排管理也会被理所当然的推广应用起来。 来自 [_The new stack_][5] 的调研数据表明，容器的推广使用是编排管理被推广的主要的催化剂。根据调研参与者的反馈数据，在已经将容器技术使用到生产环境中的使用者里，有六成正在将 kubernetes（k8s）编排管理广泛的应用在生产环境中,另外百分之十九的人员则表示他们已经处于部署 k8s 的初级阶段。在容器部署初期的使用者当中，虽然只有百分之五的人员表示已经在使用 K8s ,但是百分之五十八的人员表示他们正在计划和准备使用 K8s。总而言之，容器和 Kuebernetes 的关系就好比是鸡和蛋一样，相辅相成紧密关联。众多专家一致认为编排管理工具对容器的[长周期管理][6] 以及其在市场中的发展有至关重要的作用。正如 [Cockroach 实验室][7] 的 Alex Robinson 所说，容器编排管理被更广泛的拓展和应用是一个总体的大趋势。毫无疑问，这是一个正在快速演变的领域，且未来潜力无穷。鉴于此，我们对罗宾逊和其他的一些容器的实际使用和推介者做了采访，来从他们作为容器技术的践行者的视角上展望一下容器编排以及 k8s 的下一步发展。 From f5fe0d8712a68284b7e17c83a84aebbd34e4edde Mon Sep 17 00:00:00 2001 From: yunfengHe Date: Fri, 15 Dec 2017 21:11:36 +0800 Subject: [PATCH 16/16] =?UTF-8?q?The=20One=20in=20Which=20I=20call=20out?= =?UTF-8?q?=20Hacker=20News=20=E6=A0=A1=E5=AF=B9=E5=AE=8C=E6=AF=95?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...The One in Which I Call Out Hacker News.md | 89 +++++++++++++++++++ ...20 Containers and Kubernetes Whats next.md | 80 ----------------- 2 files changed, 89 insertions(+), 80 deletions(-) create mode 100644 translated/tech/20090701 The One in Which I Call Out Hacker News.md delete mode 100644 translated/tech/20171120 Containers and Kubernetes Whats next.md diff --git a/translated/tech/20090701 The One in Which I Call Out Hacker News.md b/translated/tech/20090701 The One in Which I Call Out Hacker News.md new file mode 100644 index 0000000000..0b06d3259a --- /dev/null +++ b/translated/tech/20090701 The One in Which I Call Out Hacker News.md @@ -0,0 +1,89 @@ +# [因为这个我要点名批评 Hacker News ][14] + + +> “实现高速缓存会花费 30 个小时，你有额外的 30 个小时吗？ +不，你没有。我实际上并不知道它会花多少时间，可能它会花五分钟，你有五分钟吗？不，你还是没有。为什么？因为我在撒谎。它会消耗远超五分钟的时间。这一切把问题简单化的假设都只不过是程序员单方面的乐观主义。” +> +> — 出自 [Owen Astrachan][1] 教授于 2004 年 2 月 23 日在 [CPS 108][2] 上的讲座 + +[指责开源软件总是离奇难用已经不是一个新论点了][5]; 这样的论点之前就被很多比我更为雄辩的人提及过, 甚至是出自一些人非常推崇开源软件的人士口中。那么为什么我要在这里老调重弹呢？ + +在周一的 Hacker News 期刊上，一段文章把我逗乐了。文章谈到，一些人认为 [编写代码实现和一个跟 StackOverflow 一样的系统可以简单到爆][6]，并自信的 [声称他们可以在7月4号的周末就写出一版和 StackOverflow 原版一摸一样的程序][7]，以此来证明这一切是多么容易。另一些人则插话说，[现有的][8][那些仿制产品][9] 就已经是一个很好的例证了。 + +秉承着自由讨论的精神，我们来假设一个场景。你在思考了一阵之后认为你可以用 ASP.NET MVC 来编写一套你自己的 StackOverflow 。我呢，在被一块儿摇晃着的怀表催眠之后，脑袋又挨了别人一顿棒槌，然后像个二哈一样一页一页的把 StackOverflow 的源码递给你，让你照原样重新拿键盘逐字逐句的在你的环境下把那些代码再敲一遍，做成你的 StackOverflow。假设你可以向我一样打字飞快，一分钟能敲100个词 ([也就是大约每秒敲八个字母][10])，但是却可以牛叉到我无法企及的打字零错误率。从 StackOverflow 的大小共计2.3MB的源码来估计（包括.CS, .SQL, .CSS, .JS 和 .aspx文件），就单单是照着源代码这么飞速敲一遍而且一气呵成中间一个字母都不错，你也要差不多用掉至少 80 个小时的时间。 + +或者你打算从零开始编码实现你自己的 StackOverflow，虽然我知道你肯定是不会那样做的。我们假设你从设计程序，到敲代码，再到最终完成调试只需要区区十倍于抄袭 StackOverflow 源代码的时间。即使在这样的假设条件下，你也要耗费几周的时间昼夜不停得狂写代码。不知道你是否愿意，但是至少我可以欣然承认，如果只给我照抄源 StackOverflow 代码用时的十倍时间来让我自己写 StackOverflow, 我可是打死也做不到。 + +_好的_，我知道你在听到这些假设的时候已经开始觉得泄气了。*你在想，如果不是全部实现，而只是实现 StackOverflow **大部分** 的功能呢？这总归会容易很多了吧。* + +好的，问题是什么是 "大部分" 功能？如果只去实现提问和回答问题的功能？这个部分应该很简单吧。其实不然，因为实现问和答的功能还要求你必须做出一个对问题和其答案的投票系统，来显示大家对某个答案是赞同还是反对。因为只有这样你才能保证提问者可以得到这个问题的唯一的可信答案。当然，你还不能让人们赞同或者反对他们自己给出的答案，所以你还要去实现这种禁止自投自票的机制。除此之外，你需要去确保用户在一定的时间内不能赞同或反对其他用户太多次，以此来防止有人用机器人程序作弊乱投票。你很可能还需要去实现一个垃圾评论过滤器，即使这个过滤器很基础很简陋，你也要考虑如何去设计它。而且你恐怕还需要去支持用户图标（头像）的功能。并且你将不得不寻找一个自己真正信任的并且 +与 Markdown 接合很好的干净的 HTML 库（当然，假设你确实想要复用 StackOverflow 的 [那个超棒的编辑器][11] ）。你还需要为所有控件购买或者设计一些小图标小部件，此外你至少需要实现一个基本的管理界面，以便那些喜欢捣鼓的用户可以调整和改动他们的个性化设置。并且你需要实现类似于 Karma 的声望累积系统，以便用户可以随着不断地使用来稳步提升他们的话语权和解锁更多的功能以及可操作性。 + +但是如果你实现了以上_所有_功能，可以说你_就已经_把要做的都做完了。 + +除非...除非你还要做全文检索功能。尤其是在“边问边搜”（动态检索）的特性中，支持全文检索是必不可少的。此外，录入和显示用户的基本信息，实现对问题答案的评论功能，以及实现一个显示热点提问的页面，以及热点问题和帖子随着时间推移沉下去的这些功能，都将是不可或缺的。另外你肯定还需要去实现回答奖励系统，并支持每个用户用多个不同的 OpenID 账户去登录，然后将这些相关的登陆事件通过邮件发送出去来通知用户，并添加一个标签或徽章系统，接着允许管理员通过一个不错的图形界面来配置这些标签和徽章（Badge）。你需要去显示用户的 Karma 历史，以及他们的历史点赞和差评。而且整个页面还需要很流畅的展开和拉伸，因为这个系统的页面随时都可能被 Slashdot，Reddit 或是 StackOverflow 这些动作影响到。 + +在这之后！你会以为你基本已经大功告成了！ + +...为了产品的完整性，在上面所述的工作都完成之后，你又奋不顾身的去实现了升级功能，界面语言的国际化，Karma 值上限，以及让网站更专业的 CSS 设计，AJAX，还有那些看起来理所当然做起来却让人吐血的功能和特性。如果你不是真的动手来尝试做一个和 StackOverflow 一摸一样的系统，你肯定不会意识到在整个程序设计实施的过程中，你会踩到无数的鬼才会知道的大坑。 + +那么请你告诉我：如果你要做一个让人满意的类似产品出来，上述的哪一个功能是你可以省略掉的呢？哪些是“大部分”网站都具备的功能，哪些又不是呢？ + +正因为这些很容易被忽视的问题，开发者才会以为做一个 StackOverflow 的仿制版产品会很简单。也同样是因为这些被忽视了的因素，开源软件才一直让人用起来很痛苦。很多软件开发人员在看到 StackOverflow 的时候，他们并不能察觉到 StackOverflow 产品的全貌。他们会简单的把 Stackoverflow 的实现抽象成下面一段逻辑和代码: + +``` +create table QUESTION (ID identity primary key, + TITLE varchar(255), --- 为什么我知道你认为是 255 + BODY text, + UPVOTES integer not null default 0, + DOWNVOTES integer not null default 0, + USER integer references USER(ID)); +create table RESPONSE (ID identity primary key, + BODY text, + UPVOTES integer not null default 0, + DOWNVOTES integer not null default 0, + QUESTION integer references QUESTION(ID)) +``` + +如果你让这些开发者去实现 StackOverflow，进入他脑海中的就是上面的两个 SQL 表和一个用以呈现表格数据的 HTML 文件。他们甚至会忽略数据的格式问题，进而单纯的以为他们可以在一个周末的时间里就把 StackOverflow 做出来。一些稍微老练的开发者可能会意识到他们还要去实现登陆和注销功能，评论功能，投票系统，但是仍然会自信的认为这不过也就是利用一个周末就能完成了；因为这些功能也不过意味着在后端多了几张 SQL 表和 HTML 文件。如果借助于 Django 之类的构架和工具，他们甚至可以直接拿来主义地不花一分钱就实现用户登陆和评论的功能。 + +但这种简单的实现却_远远不能_体现出 StackOverflow 的精髓。无论你对 StackOverflow 的感觉如何，大多数使用者似乎都同意 StackOverflow 的用户体验从头到尾都很流畅。使用 StackOverflow 的过程就是在跟一个精心打磨过的产品在愉快地交互。即使我没有深入了解过 StackOverflow ，我也能猜测出这个产品的成功和它数据库的 Schema 没有多大关系 - 实际上在有幸研读过 StackOverflow 的源码之后，我得以印证了自己的想法，StackOverflow 的成功确实和它的数据库设计关系甚小。真正让它成为一个极其易用的网站的原因，是它背后_大量的_精雕细琢的设计和实施。多数的开发人员在谈及仿制和克隆一款产品的难度时，真的_很少会去考虑到产品背后的打磨和雕琢工作_，因为他们认为_这些打磨和雕琢都是偶然的，甚至是无足轻重的。_ + +这就是为什么用开源工具去克隆和山寨 StackOverflow 其实是很容易失败的。即使这些开源开发者只是想去实现 StackOverflow 的主要的“规范和标准特性”，而非全面的高级特性，他们也会在实现的过程中遭遇种种关键和核心的问题，让他们阴沟翻船，半途而废。拿 Badge （徽章功能）来说，如果你要针对普通终端用户来设计 Badge , 则要么需要实现一个用户可用来个性化设置 bagdge 的 GUI，要么则取巧的设计出一个比较通用的 Badge 供所有的安装版本来使用。而开源设计的实际情况是，开发者会有很多的抱怨和牢骚，认为给 Badge 这种东西设计一个功能全面的 GUI 是根本不肯能的。而且他们会固执地把任何标准 badge 的提案踢回去，踢出第一宇宙速度，击穿地壳甩到地球的另一端。最终这些开发者还是会搞出一个类似于 Roundup 的 bug tracker 程序都在使用的流程和方案：即实现一个通用的机制, 提供以 Python 或 Php 为基础的一些系统API， 以便那些可以自如使用 Python 或 Php 的人可以轻松的通过这些编程接口来定制化他们自己的 Badge。而且老实说，PHP 和 Python 可是比任何可能的 GUI 接口都要好用和强大得多，为什么还要考虑 GUI 的方案呢？（出自开源开发者的想法） + +同样的，开源开发者会认为那些系统设置和管理员界面也一样可以省略掉。在他们看来，假如你是一个管理员，有 SQL 服务器的权限，那么你就理所当然的具备那些系统管理员该有的知识和技能。那么你其实可以使用 Djang-admin 或者任何类似的工具来轻松的对 StackOverflow 做很多设置和改造工作。毕竟如果你是一个 mods （懂如何mod的人）那么你肯定知道网站是怎么工作的，懂得如何利用专业工具去设置和改造一个网站。对啊！这不就得了！ 毋庸置疑，在开源开发者重做他们自己的 StackOverflow 的时候，他们也不会把任何 StackOverflow 在接口上面的失败设计纠正过来。即使是原版 StackOverflow 里面最愚蠢最失败的那个设计（即要求用户必须拥有一个 OpenID 并知道如何使用它）在某个将来最终被 StackOverflow 删除和修正掉了， 我相信正在复制 StackOverflow 模式的那些开源克隆产品也还是会不假思索的把这个 OpenID 的功能仿制出来。这就好比是 GNOME 和 KDE 多年以来一直在做的事情，他们并没有把精力放在如何在设计之初就避免 Windows 的那些显而易见的毛病和问题，相反的确是在亦步亦趋的重复着 Windows 的设计，想办法用开源的方式做出一个比拟 Windows 功能的系统。 + + +开发者可能不会关心一个应用的上述设计细节，但是终端用户一定会。尤其是当他们在尝试去选择要使用哪个应用的时候，这些终端用户更会重视这些接口设计是否易用。就好像一家好的软件公司希望通过确保其产品在出货之前就有一流的质量，以降低售后维护支持的成本一样，懂行的消费者也会在他们购买这些产品之前就确保产品好用，以防在使用的时候不知所措，然后无奈的打电话给售后来解决问题。开源产品就失败在这里，而且相当之失败。一般来讲，付费软件则在这方面做得好很多。 + +这不是说开源软件没有自己的立足之地，这个博客就运行在 Apache，[Django][12]，[PostgreSQL][13] 和 Linux 搭建的开源系统之上。但是让我来告诉你吧，配置这些堆栈可不是谁都可以做的。老版本的 PostgreSQL 需要手工配置 Vacuuming 来确保数据库的自动清理，而即使是最新版本的 ubuntu 和 FreeBSD 也仍然要求用户去手工配置他们的第一个数据库集群。 +相比之下，MS SQL (微软的 SQL) 则不需要你手工配置以上的任何一样东西。至于 Apache ... 我的天，Apache 简直复杂到让我根本来不及去尝试给一个新用户讲解我们如何可以通过一个一次性的安装过程就能把虚拟机，MovableType，几个 Diango apps 和 WordPress 配置在一起并流畅地使用。单单是给那些技术背景还不错但并非软件开发者的用户解释清楚 Apache 的那些针对多进程和多线程的设置参数就已经够我喝一壶的了。相比之下，微软的 IIS 7 或者是使用了 OS X 服务器的那个几乎闭源的 GUI 管理器的 Apache ，在配置的时候就要简单上不止一个数量级了。Django 确实是一个好的开源产品，但它也 _只是_ 一个基础构架，而并非是一个可以直接面向终端普通用户的商业产品。而开源真正的强项就 _恰恰在_ 这种基础构架的开发和创新上，这也正是驱使开发者为开源做贡献的最本真的动力。 + + +所以我的结论是，如果下次你再看到一个你喜欢的应用程序，请好好细心地揣摩一下这款产品，揣摩一下所有的那些针对用户的体贴入微的设计细节。而不是武断的认为你可以轻轻松松的再一周之内就用开源工具做一个和这个应用一摸一样的产品出来。那些认为制作和实现一个应用程序如此简单的人，十之八九都是因为忽略了软件开发的最终产品是要交给用户去用的。 + +------------------------------------------------------------------------------- + +via: https://bitquabit.com/post/one-which-i-call-out-hacker-news/ + +作者：[Benjamin Pollack][a] +译者：[hopefully2333](https://github.com/hopefully2333) +校对：[yunfengHe](https://github.com/yunfengHe) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 + +[a]:https://bitquabit.com/meta/about/ +[1]:http://www.cs.duke.edu/~ola/ +[2]:http://www.cs.duke.edu/courses/cps108/spring04/ +[3]:https://bitquabit.com/categories/programming +[4]:https://bitquabit.com/categories/technology +[5]:http://blog.bitquabit.com/2009/06/30/one-which-i-say-open-source-software-sucks/ +[6]:http://news.ycombinator.com/item?id=678501 +[7]:http://news.ycombinator.com/item?id=678704 +[8]:http://code.google.com/p/cnprog/ +[9]:http://code.google.com/p/soclone/ +[10]:http://en.wikipedia.org/wiki/Words_per_minute +[11]:http://github.com/derobins/wmd/tree/master +[12]:http://www.djangoproject.com/ +[13]:http://www.postgresql.org/ +[14]:https://bitquabit.com/post/one-which-i-call-out-hacker-news/ diff --git a/translated/tech/20171120 Containers and Kubernetes Whats next.md b/translated/tech/20171120 Containers and Kubernetes Whats next.md deleted file mode 100644 index 8e414a95dd..0000000000 --- a/translated/tech/20171120 Containers and Kubernetes Whats next.md +++ /dev/null @@ -1,80 +0,0 @@ -容器技术和 k8s 的下一站： -============================================================ -### 想知道容器编排管理和 K8s 的最新展望么？来看看专家怎么说。 - -![CIO_Big Data Decisions_2](https://enterprisersproject.com/sites/default/files/styles/620x350/public/images/CIO_Big%20Data%20Decisions_2.png?itok=Y5zMHxf8 "CIO_Big Data Decisions_2") - -如果你想对容器在未来的发展方向有一个整体把握，那么你一定要跟着钱走，看看钱都投在了哪里。当然了，有大量的资金正在投入容器的进一步发展。相关研究预计 2020 年容器技术的投入将占有 [27 亿美元][4] 的市场份额 。而在 2016 年，容器相关技术投入的总额为 7.62 亿美元，只有 2020 年投入预计的三分之一。巨额投入的背后是一些显而易见的基本因素，包括容器化的迅速增长以及并行化的大趋势。随着容器被大面积推广和使用，容器编排管理也会被理所当然的推广应用起来。 - -来自 [_The new stack_][5] 的调研数据表明，容器的推广使用是编排管理被推广的主要的催化剂。根据调研参与者的反馈数据，在已经将容器技术使用到生产环境中的使用者里，有六成正在将 kubernetes（k8s）编排管理广泛的应用在生产环境中,另外百分之十九的人员则表示他们已经处于部署 k8s 的初级阶段。在容器部署初期的使用者当中，虽然只有百分之五的人员表示已经在使用 K8s ,但是百分之五十八的人员表示他们正在计划和准备使用 K8s。总而言之，容器和 Kuebernetes 的关系就好比是鸡和蛋一样，相辅相成紧密关联。众多专家一致认为编排管理工具对容器的[长周期管理][6] 以及其在市场中的发展有至关重要的作用。正如 [Cockroach 实验室][7] 的 Alex Robinson 所说，容器编排管理被更广泛的拓展和应用是一个总体的大趋势。毫无疑问，这是一个正在快速演变的领域，且未来潜力无穷。鉴于此，我们对罗宾逊和其他的一些容器的实际使用和推介者做了采访，来从他们作为容器技术的践行者的视角上展望一下容器编排以及 k8s 的下一步发展。 - -### **容器编排将被主流接受** - -像任何重要技术的转型一样，我们就像是处在一个高崖之上一般，在经过了初期步履蹒跚的跋涉之后将要来到一望无际的广袤平原。广大的新天地和平实真切的应用需求将会让这种新技术在主流应用中被迅速推广，尤其是在大企业环境中。正如 Alex Robinson 说的那样，容器技术的淘金阶段已经过去，早期的技术革新创新正在减速，随之而来的则是市场对容器技术的稳定性和可用性的强烈需求。这意味着未来我们将不会再见到大量的新的编排管理系统的涌现，而是会看到容器技术方面更多的安全解决方案，更丰富的管理工具，以及基于目前主流容器编排系统的更多的新特性。 - -### **更好的易用性** - -人们将在简化容器的部署方面下大功夫，因为容器部署的初期工作对很多公司和组织来说还是比较复杂的，尤其是容器的[长期管理维护][8]更是需要投入大量的精力。正如 [Codemill AB][9] 公司的 My Karlsson 所说，容器编排技术还是太复杂了，这导致很多使用者难以娴熟驾驭和充分利用容器编排的功能。很多容器技术的新用户都需要花费很多精力，走很多弯路，才能搭建小规模的，单个的，被隔离的容器系统。这种现象在那些没有针对容器技术设计和优化的应用中更为明显。在简化容器编排管理方面有很多优化可以做，这些优化和改造将会使容器技术更加具有可用性。 - -### **在 hybrid cloud 以及 multi-cloud 技术方面会有更多侧重** - -随着容器和容器编排技术被越来越多的使用，更多的组织机构会选择扩展他们现有的容器技术的部署，从之前的把非重要系统部署在单一环境的使用情景逐渐过渡到更加[复杂的使用情景][10]。对很多公司来说，这意味着他们必须开始学会在 [hybrid cloud][11] 和 [muilti-cloud][12] 的环境下，全局化的去管理那些容器化的应用和微服务。正如红帽 [Openshift 部门产品战略总监][14] [Brian Gracely][13] 所说,容器和 k8s 技术的使用使得我们成功的实现了混合云以及应用的可移植性。结合 Open Service Broker API 的使用，越来越多的结合私有云和公有云资源的新应用将会涌现出来。 -据 [CloudBees][15] 公司的高级工程师 Carlos Sanchez 分析，联合服务（Federation）将会得到极大推动，使一些诸如多地区部署和多云部署等的备受期待的新特性成为可能。 - -**[ 想知道 CIO 们对 hybrid cloud 和 multi cloud 的战略构想么? 请参看我们的这条相关资源， **[**Hybrid Cloud: The IT leader's guide**][16]**. ]** - -### **平台和工具的持续整合及加强** - -对任何一种科技来说，持续的整合和加强从来都是大势所趋; 容器编排管理技术在这方面也不例外。来自 [Sumo Logic][17] 的首席分析师 Ben Newton 表示，随着容器化渐成主流，软件工程师们正在很少数的一些技术上做持续整合加固的工作，来满足他们的一些微应用的需求。容器和 K8s 将会毫无疑问的成为容器编排管理方面的主流平台，并轻松碾压其他的一些小众平台方案。因为 K8s 提供了一个相当清晰的可以摆脱各种特有云生态的途径，K8s 将被大量公司使用，逐渐形成一个不依赖于某个特定云服务的“中立云”（cloud-neutral）。 - -### **K8s 的下一站** - -来自 [Alcide][18] 的 CTO 和联合创始人 Gadi Naor 表示，k8s 将会是一个有长期和远景发展的技术，虽然我们的社区正在大力推广和发展 k8s，k8s 仍有很长的路要走。 -专家们对[日益流行的 k8s 平台][19]也作出了以下一些预测： - -**_来自 Alcide 的 Gadi Naor 表示:_** “运营商会持续演进并趋于成熟，直到在 k8s 上运行的应用可以完全自治。利用 [OpenTracing][20] 和诸如 [istio][21] 技术的 service mesh 架构，在 k8s 上部署和监控微应用将会带来很多新的可能性。” - -**_来自 Red Hat 的 Brian Gracely 表示:_** “k8s 所支持的应用的种类越来越多。今后在 k8s 上，你不仅可以运行传统的应用程序，还可以运行原生的云应用，大数据应用以及 HPC 或者基于 GPU 运算的应用程序，这将为灵活的架构设计带来无限可能。” - -**_来自 Sumo Logic 的 Ben Newton 表示:_** “随着 k8s 成为一个具有统治地位的平台，我预计更多的操作机制将会被统一化，尤其是 k8s 将和第三方管理和监控平台融合起来。” - -**_来自 CloudBees 的 Carlos Sanchez 表示:_** “在不久的将来我们就能看到不依赖于 Docker 而使用其他运行时环境的系统，这将会有助于消除任何可能的 lock-in 情景“ [小编提示：[CRI-O][22] 就是一个可以借鉴的例子。]“而且我期待将来会出现更多的针对企业环境的存储服务新特性，包括数据快照以及在线的磁盘容量的扩展。” - -**_来自 Cockroach Labs 的 Alex Robinson 表示:_** “ k8s 社区正在讨论的一个重大发展议题就是加强对[有状态程序][23]的管理。目前在 k8s 平台下,实现状态管理仍然非常困难，除非你所使用的云服务商可以提供远程固定磁盘。现阶段也有很多人在多方面试图改善这个状况，包括在 k8s 平台内部以及在外部服务商一端做出的一些改进。” - -------------------------------------------------------------------------------- - -via: https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next - -作者：[Kevin Casey ][a] -译者：[yunfengHe](https://github.com/yunfengHe) -校对：[校对者ID](https://github.com/校对者ID) - -本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出 - -[a]:https://enterprisersproject.com/user/kevin-casey -[1]:https://enterprisersproject.com/article/2017/11/kubernetes-numbers-10-compelling-stats -[2]:https://enterprisersproject.com/article/2017/11/how-enterprise-it-uses-kubernetes-tame-container-complexity -[3]:https://enterprisersproject.com/article/2017/11/5-kubernetes-success-tips-start-smart?sc_cid=70160000000h0aXAAQ -[4]:https://451research.com/images/Marketing/press_releases/Application-container-market-will-reach-2-7bn-in-2020_final_graphic.pdf -[5]:https://thenewstack.io/ -[6]:https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul -[7]:https://www.cockroachlabs.com/ -[8]:https://enterprisersproject.com/article/2017/10/microservices-and-containers-6-management-tips-long-haul -[9]:https://codemill.se/ -[10]:https://www.redhat.com/en/challenges/integration?intcmp=701f2000000tjyaAAA -[11]:https://enterprisersproject.com/hybrid-cloud -[12]:https://enterprisersproject.com/article/2017/7/multi-cloud-vs-hybrid-cloud-whats-difference -[13]:https://enterprisersproject.com/user/brian-gracely -[14]:https://www.redhat.com/en -[15]:https://www.cloudbees.com/ -[16]:https://enterprisersproject.com/hybrid-cloud?sc_cid=70160000000h0aXAAQ -[17]:https://www.sumologic.com/ -[18]:http://alcide.io/ -[19]:https://enterprisersproject.com/article/2017/10/how-explain-kubernetes-plain-english -[20]:http://opentracing.io/ -[21]:https://istio.io/ -[22]:http://cri-o.io/ -[23]:https://opensource.com/article/17/2/stateful-applications -[24]:https://enterprisersproject.com/article/2017/11/containers-and-kubernetes-whats-next?rate=PBQHhF4zPRHcq2KybE1bQgMkS2bzmNzcW2RXSVItmw8 -[25]:https://enterprisersproject.com/user/kevin-casey