Maybe one of the most important qualities of a developer is the ability to pick the right tool for the right job, without hopping onto bandwagons or reinventing the wheel. This might require a bit of technology analysis, but even more, a touch of critical thinking.
开发人员最重要的素质之一就是能够为正确的工作选择合适的工具，而不必跳上潮流或重新发明轮子 。 这可能需要进行一些技术分析，但还需要一些批判性思维。
Here is a review of a few exaggerated trends and underrated niceties, in different areas of the marvelous world of computer science: databases, asynchronicity, cryptocurrency, and data formats. I won't touch on the subject of REST webservices, which I already ranted about at great length.
这是对计算机科学这个奇妙世界中不同领域的一些夸大趋势和被低估的地方的回顾： 数据库，异步性，加密货币和数据格式 。 我不会涉及REST Web服务这一主题，我已经对此进行了长时间的讨论 。
As usual, your feedback is more than welcome if any factual errors slipped into this (not entirely unbiased) article.
与往常一样，如果这篇文章(并非完全没有偏见)中有任何事实错误，欢迎您提供反馈。
数据库：NoSQL和ZODB (Databases: NoSQL & ZODB)
Few moments, in the history of computer science, were as ironically lit as the arrival of No-SQL databases, around 2009. A tidal wave struck the shores of backend development and system administration: SQL databases were too rigid, too slow, too hard to replicate.
具有讽刺意味的是，在计算机科学史上，几乎没有什么像No-SQL数据库在2009年左右到来时那样。具有讽刺意味的是，后端开发和系统管理的浪潮席卷而来：SQL数据库太僵化，太慢，太难了复制。
So new projects massively ditched them in favor of key-value stores like Redis, document-oriented databases like MongoDB/CouchDB, or graph-oriented databases like Neo4j. And we must acknowledge one thing: these new databases shone in benchmarks; they shone about as much.... as would shine any SQL database dropping all its ACID constraints and query language flexibility.
因此，新项目大量抛弃了它们，转而支持键值存储(如Redis)，面向文档的数据库(如MongoDB / CouchDB)或面向图形的数据库(如Neo4j)。 我们必须承认一件事：这些新数据库在基准测试中发光； 他们大放异彩....就像任何SQL数据库删除其所有ACID约束和查询语言灵活性一样。
But the horizon was grim for numerous programmers. They learned, the hard way, that data persistence was not a minor concern. And that they needed, for example, to explicitly activate "Write Concerns" in MongoDB, to ensure that data would not get lost before reaching disk oxide.
但是，对于许多程序员来说，前景还是很严峻的。 他们艰难地了解到数据持久性并不是一个小问题。 并且，例如，他们需要在MongoDB中显式激活“写入问题”，以确保数据在到达磁盘氧化层之前不会丢失。
They learned that "eventual consistency" was a pretty word for "temporary inconsistency", opening the door to nasty, silent, hard-to-reproduce bugs in production. And that transactions - and their implicit locking - were precious features, and that mimicking them by hand, with awkward flags stuffed into documents, was all but easy and robust.
他们了解到，“最终一致性”是“临时不一致”的漂亮词汇，为生产中令人讨厌，无声且难以复制的错误打开了大门。 而且，交易及其隐式锁定是非常宝贵的功能，而手工模仿它们，并在文档中填充笨拙的标志，则几乎既简单又健壮。
And they learned that data schemas, and referential integrity, were more than welcome to prevent databases from becoming heaps of incoherent objects. And that the lack of advanced indexing capabilities (on multiple keys, on deep document fields) in key-value stores could become quite embarrassing.
他们了解到，为了防止数据库成为不相关对象的堆，非常欢迎使用数据模式和引用完整性。 而且键值存储中缺少高级索引功能(在多个键上，在深层文档字段上)可能会很尴尬。
Thus, people began reinventing SQL features on top of NoSQL databases, by mimicking data schemas, foreign keys, advanced aggregation, in language-specific "ORM" libraries (mongoengine, mongoid, mongomapper...). In this context, this "Object-Relational Mapper" acronym should have, by itself, been a hint that something had gone wild.
因此，人们开始模仿特定于语言的“ ORM”库(mongoengine，mongoid，mongomapper ...)中的数据模式，外键，高级聚合，从而在NoSQL数据库之上重塑SQL功能。 在这种情况下，“对象关系映射器”的首字母缩略词本身应该暗示某些事情已经变得疯狂。
There was something surreal in watching NoSQL databases, which were honed for specific use cases (highly replicated or heterogeneous data, capped-size collections or TTLs, pub/sub systems...), be used just to store a bunch of same-shape objects in a single server instance.
在观察NoSQL数据库时有一些超现实的东西，这些数据库针对特定的用例(高度复制或异构的数据， 限定大小的集合或TTL ，发布/ 订阅系统...)而磨练，仅用于存储一堆相同形状的数据一个服务器实例中的对象。
A standard SQL database would completely have done the job, and offered many more tooling options and plugins (different storage engines, Percona toolkit scripts, IDEs like HeidiSql or Mysql Workbench, DB schema migration processes integrated into web frameworks...). Even if it meant stuffing extra unstructured data into a serialized Text Field (or, nowadays, dedicated PostgreSQL Json Fields).
一个标准SQL数据库将完全完成这项工作，并提供更多的工具选项和插件(不同的存储引擎，Percona工具包脚本，IDE(例如HeidiSql或Mysql Workbench)，集成到Web框架中的DB模式迁移过程...)。 即使这意味着将多余的非结构化数据填充到序列化的Text Field(或如今的专用PostgreSQL Json Fields )中。
With time, NoSQL databases themselves improved a lot, among other things by borrowing features from the SQL world. But reinventing SQL is not an easy task. Relational databases deal with query language parsing, character sets and collations, data aggregation and conversion, transactions and isolation levels, views and query caches, triggers, embedded procedures, GIS, fine-grained permissions, replication and clustering... complex and sensitive features, driven by hundreds of settings spread on multiple levels (per database, per table, per connection).
随着时间的流逝，NoSQL数据库本身有了很大的改进，尤其是通过借鉴SQL世界的功能。 但是，重塑SQL并非易事。 关系数据库处理查询语言解析，字符集和归类，数据聚合和转换，事务和隔离级别，视图和查询缓存，触发器，嵌入式过程， GIS ，细粒度权限，复制和群集...复杂而敏感的功能，由分布在多个级别(每个数据库，每个表，每个连接)的数百个设置驱动。
So despite their great progress (multi-document transactions, better data aggregation, stored JavaScript functions, pluggable storage, role-based access control in MongoDB), NoSQL DBs still have trouble challenging major SQL databases, purely feature-wise.
因此，尽管NoSQL数据库取得了长足的进步(多文档事务，更好的数据聚合，JavaScript存储功能，可插拔存储，MongoDB中基于角色的访问控制)，但从功能上来讲，仍然难以挑战主要SQL数据库。
Luckily, most projects only need a tiny subset of these SQL database features: a few schema validations, a few proper indices, and business can get rolling; so for teams lacking SQL expertise, the relative simplicity of many NoSQL DBs could indeed be, to be honest, a relevant factor.
幸运的是，大多数项目仅需要这些SQL数据库功能的一小部分：一些模式验证，一些适当的索引，并且业务可以滚动； 因此，对于缺乏SQL专业知识的团队，说实话，许多NoSQL DB的相对简单性确实可能是一个相关因素。
The wave seems to have faded by now, and projects seem more inclined to combine different databases according to actual needs. They thus separate user accounts, job queues and similar caches, logging and stats data... each into the most relevant storage.
到目前为止，这一浪潮似乎已经消失，项目似乎更倾向于根据实际需要组合不同的数据库。 因此，他们将用户帐户，作业队列和类似的缓存，日志记录和统计数据……分别存储到最相关的存储中。
All these cited NoSQL databases, and their countless alternatives, are shining in their intended use cases. But I'd like to mention a too-little-known, too-little-used gem of the Python ecosystem. Have you already wanted to persist your data in a really, reaaaalllly easy way? Then I forward you to the ZODB. You open it like a dictionary, you push whatever data you want into it, you commit the transaction, and you're good to go.
所有这些引用的NoSQL数据库及其无数替代方案，在其预期的用例中大放异彩。 但我想提一下Python生态系统中鲜为人知，使用很少的瑰宝。 您是否已经想过以一种真正非常简单的方式来保留数据？ 然后，我将您转发到ZODB 。 您像打开字典一样打开它，将所需的任何数据推入其中，提交事务，一切顺利。
Example of simple local ZODB instance:
简单的本地ZODB实例示例：
from ZODB import FileStorage, DB
import transaction
storage = FileStorage.FileStorage('mydatabase.fs')
root = DB(storage).open().root()
print("ROOT:", root)
root['employees'] = ['Mary', 'Jo', 'Bob']
transaction.commit()Graphs of data are handled gracefully (no recursion error), objects are lazily loaded on access, special "bucket tree" types are provided to browse huge amounts of data while keeping memory low, and several storage backends exist, including relstorage which leverages the power of SQL databases. Perfect, isn't it?
数据的图表，是优雅的处理(没有递归误差)，对象是延迟加载的访问，提供了特殊的“斗树”类型，浏览大量的数据，同时保持记忆低，和几个存储后端存在，包括relstorage它利用电力SQL数据库。 完美，不是吗？
Alright, I'm lying, there are a few gotchas. There is no built-in indexing system (one must use Zcatalog or the likes instead). Using dedicated "persistent" types is highly advised, to automatically detect and persist mutations of objects. The overall tooling is quite limited compared to mainstream databases. And the concurrency model based on "optimistic locking" might force you, under heavy load, to retry an operation several times until it manages to get applied.
好吧，我在撒谎，有一些陷阱。 没有内置的索引系统(必须使用Zcatalog或类似工具代替)。 强烈建议使用专用的“持久”类型，以自动检测并保持对象的突变。 与主流数据库相比，整体工具非常有限。 并且基于“乐观锁定”的并发模型可能会在重负载下迫使您重试几次操作，直到成功应用。
The extreme amount of integration with the Python language has an additional drawback: if you introduce breaking changes into your data model, your database might not load anymore, so you must handle schema migrations carefully.
与Python语言的大量集成还有一个缺点：如果在数据模型中引入重大更改，则数据库可能不再加载，因此必须谨慎处理模式迁移。
But context is everything: ZODB is not meant for long term and interoperable data persistence, but for effortless storage of (possibly very heterogeneous) python objects. It can make long-running scripts able to resume after interruption, it can store player data of online game sessions... if you really want to store blog articles or personal accounts in ZODB, you had better limit yourself to native python types, and implement your own sanity checks. But whatever happens, do not use a very limited stdlib shelf, if you can have a nifty ZODB under the hand to store your work-in-progress data.
但是上下文是一切：ZODB并不是为了长期和可互操作的数据持久性，而是为了轻松存储(可能是非常异构的)python对象。 它可以使长时间运行的脚本能够在中断后恢复运行，可以存储在线游戏会话的玩家数据……如果您真的想将博客文章或个人帐户存储在ZODB中，则最好将自己限制在本机python类型，并且实施您自己的健全性检查。 但是无论发生什么情况，如果您手边有一个漂亮的ZODB来存储正在进行的数据，请不要使用非常有限的stdlib架子 。
异步性：Asyncio，Trio和Green线程 (Asynchronicity: Asyncio, Trio and Green Threads)
There has been an immemorial challenge between synchronous and asynchronous programming models, in all IO-bound programs. Kernels have provided asynchronous modes for disk operations, with more or less success (overlapped non-blocking IO on Windows, limited io_submit() API on Linux...).
在所有IO绑定程序中，同步和异步编程模型之间都存在着远古的挑战。 内核已为磁盘操作提供了异步模式，或多或少都取得了成功(Windows上重叠无阻塞IO，Linux上有限的io_submit ()API ...)。
Networking code has made the issue still more acute, with the need for huge numbers of long-term connections, each performing only minor CPU operations.
联网代码使问题更加严重，需要大量的长期连接，每个连接仅执行较小的CPU操作。
Some languages, like Erland, confronted this by being asynchronous from the start, and letting different tasks communicate by message passing (a.k.a Actor Model).
诸如Erland之类的某些语言从一开始就处于异步状态，并通过消息传递(即Actor Model )让不同的任务进行通信。
In other languages, several design patterns emerged to tackle the problem:
用其他语言，出现了几种设计模式来解决该问题：
- callbacks 回叫
- async/await syntax 异步/等待语法
- lightweight threads 轻量级线程
Callbacks were previously the major solution in mainstream frameworks. For example in jQuery or Twisted, the developer would provide callables as arguments or as instance methods, and these would be called on IO completion/cancellation, in a pattern called Inversion of Control. It works, for sure, but it makes program flows quite hard to predict and debug, hence the term "callback soup" often used in this context.
回调是以前主流框架中的主要解决方案。 例如，在jQuery或Twisted中，开发人员将提供可调用对象作为参数或实例方法，并且这些对象将在IO完成/取消时以称为Inversion of Control的模式被调用。 当然，它可以工作，但是却使程序流很难预测和调试，因此在此上下文中经常使用“回调汤”一词。
For the last few years, the async/await syntax has become highly trendy, especially in the Python world. But there is a problem: like Inversion of Control, it's a whole new way of programming, almost a new language. The vast amount of packages currently available, made of modules, classes and methods, just does NOT work with async/await.
在过去的几年中， 异步/等待语法变得非常流行，尤其是在Python世界中。 但是有一个问题：像控制反转一样，这是一种全新的编程方式，几乎是一种新语言。 当前可用的由模块，类和方法组成的大量程序包不适用于async / await。
Any IO, any expensive operation, hidden deep inside a subdependency, could ruin your day. So we're currently gazing at thousands of great modules being happily reimplemented, with a whole new world of bugs and missing features.
隐藏在子依赖关系内部的任何IO，任何昂贵的操作都可能破坏您的一天。 因此，我们目前正在注视着成千上万个很棒的模块，它们被幸福地重新实现，带有一个全新的错误世界和缺少的功能。
Is it all worth it? Python developers have massively jumped onto the train of the asyncio package, which has become part of the stdlib. But this technology has scary issues, like the difficulty of socket backpressure, the fragile handling of exceptions and ctrl-C, the unsafe cancellation of (leaking) tasks, and the steep learning curve of an API full of gotchas and redundant concepts. Other frameworks like Trio/Curio, seemed much more careful on these subjects.
值得吗？ Python开发人员已大量使用asyncio软件包，该软件包已成为stdlib的一部分。 但是这项技术有一些可怕的问题，例如套接字背压的难度，异常和ctrl-C的脆弱处理，(泄漏的)任务的不安全取消以及充满陷阱和冗余概念的API的陡峭学习曲线。 在这些主题上 ，诸如Trio / Curio之类的其他框架似乎要谨慎得多 。
If we have to recode tons of existing libraries, why base new versions on an engine that some developers have - not without arguments - called a dumpster fire of bad design? But the network effect is huge in such cases, and alternative async/await-based frameworks will have a hard time challenging the standard.
如果我们必须重新编码大量现有的库，为什么将新版本基于某些开发人员具有引擎的引擎(而不是没有参数)，这种引擎被称为设计不良的垃圾箱 ？ 但是在这种情况下， 网络影响巨大，并且基于异步/等待的替代框架将很难挑战标准。
And what about the third pattern quoted above, lightweight threads? Long before this async/await trend, Python developers thought: we already have some perfectly fine synchronous business code, so let's change the way it is run, not the way it is written. Thus appeared lightweight threads, or "greenlets". They work like a bunch of tiny tasks scheduled on top of a few native threads, tasks which yield control to each other only when they block on IO or explicitly do so; and with much greater performance than native threads, in terms of memory usage and switching delay.
上面引用的第三个模式轻量级线程又如何呢？ 早于这种异步/等待趋势，Python开发人员就想到：我们已经有了一些完美的同步业务代码，因此让我们更改其运行方式，而不是其编写方式。 因此出现了轻量级线程或“ greenlets”。 它们就像在一些本机线程上调度的一堆小任务一样工作，这些任务仅在它们阻塞或显式阻塞IO时才相互控制。 并且在内存使用和切换延迟方面比本地线程具有更高的性能。
In the end, this system can quickly boost about any existing codebase so that it supports thousands of long-term concurrent tasks. And this is not an isolated mad experiment: Python lightweight threads have originally been used in Eve Online game (via Stackless Python), and have since successfully been ported to CPython (Gevent, Eventlet...) and PyPy. And they have actually existed for a long time in lots of programming languages, under different names (green processes, green threads, fibers...).
最后，该系统可以快速扩展任何现有代码库，从而支持数千个长期并发任务。 这不是一个孤立的疯狂实验：Python轻量级线程最初用于Eve Online游戏(通过Stackless Python)，并且此后已成功移植到CPython(Gevent，Eventlet ...)和PyPy。 实际上，它们已经以许多不同的名称(绿色进程，绿色线程，光纤...)在许多编程语言中存在了很长时间 。
The drawbacks of this system?
这个系统的弊端？
- Libraries must play nice with green threads, by yielding control instead of blocking on IOs, and launching green threads instead of native threads. In python, main libraries (socket, time.sleep(), threading) are forcibly made green-friendly via monkey-patching; but compiled extensions must be especially checked, since they can bypass these patches and block on their own system calls. 库必须通过释放控制而不是阻塞IO并启动绿色线程而不是本机线程来与绿色线程配合使用。 在python中，通过猴子补丁强制将主要库(socket，time.sleep()，线程)设为绿色友好； 但是必须特别检查已编译的扩展，因为它们可以绕过这些修补程序并在自己的系统调用中阻止。
No heavy computation, or otherwise time-consuming tasks, must be performed, else all other tasks get impacted by the delay. For such needs, just delegate work to a pool of native threads (or a celery-like worker queue).
无需执行繁重的计算或其他费时的任务，否则所有其他任务都会受到延迟的影响。 对于此类需求，只需将工作委派给本地线程池(或类似celery的工作人员队列)即可。
As we see, these drawbacks are similar to those of async/await, except that you almost don't have to touch the original, synchronous code. An "except" which can mean months or years of work avoided ; your CTO and CEO should be highly pleased about this.
正如我们所看到的，这些缺点与async / await的缺点相似，不同之处在于您几乎不必触摸原始的同步代码。 “例外”可能意味着可以避免工作数月或数年； 您的CTO和CEO应该对此感到非常高兴。
Now, you'll sometimes hear strange rationalizations from people who ditched lightweight threads in favor of a whole async/await reimplementation. Something in the lines of "Explicit is better than implicit, and all these awaits show me exactly where my code could switch context, whereas green threads might switch discreetly if a third-party function performs any kind of IO or explicit switch".
现在，您有时会听到放弃轻量级线程以支持整个异步/等待重新实现的人提出奇怪的合理化解释。 “ 显式比隐式更好，所有这些等待都向我展示了我的代码可以在哪里切换上下文，而如果第三方函数执行任何类型的IO或显式切换，则绿色线程可能会谨慎切换 ”。
But the thing is...
可是...
FIRST, why do you need to know at which points exactly the program will switch to another task? For all the past years, with native (preemptive) thread, a switch could happen anywhere, anytime, even right in a middle of a simple increment.
首先，为什么您需要知道程序将在哪一点准确地切换到另一个任务？ 在过去的几年中，使用本机(抢占式)线程，切换可以在任何地方，任何时间发生，即使只是在简单的增量中间进行。
But we learned to deal with this invisible threat properly, by protecting critical sections with locks and other synchronization primitives (Recursive Locks, Event, Condition, Semaphore...), keeping a proper order when nesting locks, and using thread-safe data structures (Queues and the likes) which handle concurrency for us.
但是，我们学会了通过使用锁和其他同步原语(递归锁，事件，条件，信号量...)保护关键部分，在嵌套锁时保持适当的顺序，并使用线程安全的数据结构来适当地应对这种无形的威胁。 (队列等)为我们处理并发。
Green threads are a middle ground between (implicit) preemptive threads and (explicit) async/await, but all of these technologies had better stick to the good old way of protecting concurrent operations.
绿色线程是(隐式)抢占线程和(显式)异步/等待之间的中间地带，但是所有这些技术最好都采用保护并发操作的旧方法。
Locks can be dangerous when misused (especially since most implementations stall, instead of detecting deadlock and reporting them as exceptions), but they are cheap and robust. What is the point of attempting to do lock-less concurrency, by checking the position of each potentially switch-triggering calls, when you could anytime have to add a new operation (even a simple logging output) in the middle of your carefully crafted lock-less sequence, and thus ruin its safety?
锁在滥用时可能很危险(特别是因为大多数实现会停滞，而不是检测死锁并将其报告为异常)，但是它们既便宜又健壮。 通过检查每个潜在的触发开关的调用的位置来尝试进行无锁并发的意义何在，何时您可能随时需要在精心设计的锁中间添加新操作(甚至是简单的日志输出)少顺序，从而破坏其安全性？
This naive code shows how a recently added call to log_counter_value() breaks an otherwise safe asynchronous code.
这个朴素的代码显示了最近添加的对log_counter_value()的调用如何破坏本来安全的异步代码。
async def increment_counter(counter):
current = counter.current_value
await log_counter_value(current) # Unwanted context switch happens here
counter.current_value = current + 1SECOND, do you really have to deal with synchronization? In the web world especially, where HTTP requests are not supposed to interact, we want parallelization, not concurrency. Persistent data (and transactions) are supposed to be handled by external databases and caches, not in process memory heap.
第二，您真的需要处理同步吗？ 尤其是在不应与HTTP请求进行交互的网络世界中，我们希望并行化而不是并发。 持久性数据(和事务)应该由外部数据库和缓存处理，而不是在进程内存堆中处理。
So usual thread-safety good practices (using thread-safe initialization of the process via locks, read-only structures for global data, and read-write data only local to stack frames) are enough to make the whole system "thread/greenlet/asynctask safe".
因此，通常的线程安全良好做法(通过锁使用进程的线程安全初始化，用于全局数据的只读结构以及仅对堆栈帧局部的读写数据)足以使整个系统成为“线程/ greenlet / asynctask安全”。
If one day you need to implement highly concurrent algorithms inside a process, you'll choose the best tool for that, but no need for hammer-building factories if all you have to do is thrust one nail.
如果有一天您需要在一个流程中实现高度并发的算法，那么您将为此选择最佳的工具，但是如果您要做的只是推钉子，就不需要锤子建造工厂。
金钱：比特币和替代品 (Money: Bitcoins & Alternatives)
Let's ponder for a moment. What are the biggest challenges of our 21st century? Climate change? Tax evasion? Legitimacy of state power? So candid minds could think that energetic sobriety, financial traceability, and (really) democratic organizations, would be goals to pursue.
让我们考虑一下。 我们21世纪最大的挑战是什么？ 气候变化？ 逃税？ 国家权力的合法性？ 因此，坦率的头脑可能会认为，精力充沛的清醒，财务可追溯性和(真的)民主组织将是追求的目标。
But a group of smart hackers decided that current moneys were a major issue, and came up with Bitcoins: energy-devouring "proof of work" system, easy anonymity of money holders, and fuzzy (for the least) governance.
但是一群聪明的黑客认为当前的钱是一个主要问题，于是提出了比特币：消耗能量的“工作量证明”系统，资金持有者容易匿名，以及(至少)模糊的治理。
With such adequation between needs and demand, it's no wonder that Bitcoins became what they became: a product of (almost) pure speculation, praised by ransomwares and miscellaneous mafias, mass-mined by factories of graphics cards, with an especially high appetite for being stolen (or lost).
随着需求和需求之间的这种adequation，这也难怪，比特币成为了他们成了什么：的(几乎)纯属猜测，通过称赞产品ransomwares和杂项黑手党，大规模开采的显卡工厂，拥有特别高的胃口是被盗 (或丢失)。
This money, and its soon-emerged siblings, have a history already full of bewildering moments, with accidental chain splits, soft forks blocked for political reasons, hard forks quite arbitrarily decided by miscellaneous people (or forced by cyber attacks), and endless battles between different currencies, or different versions of the same currency (Bitcoin Core, Cash, Gold, SV...). Algorithms (cryptography, consensus, transaction code...) were praised as the foundations of a bullet-proof and self-governing system, but some actors had to hack their own users to protect them from theft, while even the so glorified "smart contracts" showed loads of scary security weaknesses, and not as many use cases as some expected.
这笔钱及其即将出现的兄弟姐妹的历史已经充满了令人迷惑的时刻，意外的链条断裂，出于政治原因而封锁了软叉 ，由杂种人任意决定硬叉 (或由网络攻击迫使)，以及无休止的战斗在不同货币或相同货币的不同版本之间(比特币核心，现金，黄金，SV ...)。 算法(加密，共识，交易代码...)被认为是防弹和自我管理系统的基础，但是一些参与者不得不黑客自己的用户以保护他们免遭盗窃，即使如此夸张的“智能”合同”显示了许多令人恐惧的安全弱点 ，而且用例没有预期的那么多。
Let's make it clear: the blockchain, a public ledger based on Merkle trees, is far from a bad idea. But when decisions are not based on the needs of society, and carefulness regarding bugs, but on ideology and greed, the outcome can be predicted. And the decline in hype is proportional to unduly invested hopes.
让我们说清楚：区块链是基于Merkle树的公共分类帐，绝不是一个坏主意。 但是，当决策不是基于社会的需求，对错误的谨慎而基于意识形态和贪婪时，则可以预测结果。 炒作的减少与过度投资的希望成正比。
What is the "better" counterpart of Bitcoin, Ethereum, and the like? Lots of alternative cryptocurrencies exist, with lighter forms of authorization, with different crypto algorithms, with different privacy settings, with different adoption rates too... But if you ask me, what we would really need is "an easily traceable money for State finances and NGOs"; a public ledger designed so that any citizen could easily audit how public money is used, from the moment it's gathered via taxes and donations, to the moment it gets back into private circuits by paying goods or employee salaries. Does anything like this exist yet, anyone? Couldn't find it...
比特币，以太坊等的“更好”对应是什么？ 存在许多替代的加密货币，其授权形式较轻，加密算法不同，隐私设置不同，采用率也不同。但是，如果您问我，我们真正需要的是“ 可轻松追回的国家资金”和非政府组织 ”； 一种公共分类帐，其设计目的是使任何公民都可以轻松地审核从税收和捐赠收集公款到通过支付商品或员工薪金回到私人巡回商的公款的使用方式。 有人这样存在吗？ 找不到...
One could also mention non-cryptographic but local moneys (ex. the "Gonette" in Lyon, France), kept on parity with national moneys, which have the advantage of favoring local businesses and thus lowering the collateral damages of international trade.
人们还可以提到非加密但本地 货币 (例如法国里昂的“ Gonette ”)，与本国货币持平 ，其优点是有利于本地企业，从而降低了国际贸易的附带损害。
数据格式：文本和二进制 (Data Formats: Text and Binary)
A witty passerby once defined XML as "the readability of binary data with the efficiency of text". Indeed XML parsers tend to be sluggish, and to clutter memory (when in DOM mode), compared to binary data loaders; and editing XML configurations and documents by hand is not the best user experience one might have.
一位机智的过路人曾经将XML定义为“ 具有文本效率的二进制数据可读性 ”。 实际上，与二进制数据加载器相比，XML解析器往往比较迟钝，并且内存混乱(在DOM模式下)。 手动编辑XML配置和文档并不是一种最佳的用户体验。
We easily understand why XML, as a metalanguage allowing to create new tags and properties for all kinds of uses, needs to be so verbose. But why such enthusiasm for text-based formats, when the goal is to transmit information between servers using well-defined data types ?
我们很容易理解为什么XML作为一种元语言，可以为各种用途创建新的标签和属性，所以它需要那么冗长。 但是，当目标是使用定义良好的数据类型在服务器之间传输信息时，为什么对基于文本的格式如此热情呢？
Parsing HTTP payloads into an internal representation, and then parsing, for example, its JSON body, ends up adding significant overhead to webservice requests. For what gain ? Binary formats like Bson would make the serialization/deserialization much more performant; and semantically equivalent text formats could be used for debugging (auto-converted by web browser dev tools, Wireshark, CURL and the likes), and for manually crafting test payloads.
将HTTP有效负载解析为内部表示形式，然后解析其JSON主体，最终会给Web服务请求增加大量开销。 有什么收获？ 像Bson这样的二进制格式将使序列化/反序列化的性能更高； 语义上等效的文本格式可用于调试(由Web浏览器开发工具，Wireshark，CURL等自动转换)，以及用于手工制作测试有效负载。
For sure, handling these dual representations of the same data would add a bit of complexity to the system, but in an era when startups love exposing webservices to thousands simultaneous clients, the performance boost can be real, with not so much effort.
当然，处理相同数据的这些双重表示会给系统增加一点复杂性，但是在一个新兴企业喜欢将Web服务公开给成千上万个同时出现的客户端的时代，性能提升可以是实实在在的，而无需付出太多努力。
结论 (Conclusion)
What's the moral of all this? Always the same, "use the right tool for the right job, and beware of irrational fads". It can take lots of reading before one has a sufficient depth of view, on a specific matter, to take educated decisions; but this investment quickly pays off.
这一切的寓意是什么？ 始终如一，“ 使用正确的工具完成正确的工作，并提防非理性风尚 ”。 在对特定问题有足够的见识之前，可能需要大量阅读才能做出有根据的决策； 但这笔投资很快就会得到回报。
Guessing how well a framework will be supported on the long-term, or which protocol/format will win a standardization war, is a different problem, but at least we can have our opinions firmly founded, when it comes to purely technical aspects, and this is Gold.
猜测框架将长期得到多大支持，或者哪种协议/格式将赢得标准化之战，这是一个不同的问题，但是就纯粹的技术方面而言，至少我们可以牢固地建立自己的观点，并且这是金。
翻译自: https://www.freecodecamp.org/news/software-fads-and-gems/
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
