diff --git a/translated/tech/20190416 Can schools be agile.md b/published/20190416 Can schools be agile.md similarity index 84% rename from translated/tech/20190416 Can schools be agile.md rename to published/20190416 Can schools be agile.md index 83f051f11f..1e696ab2cd 100644 --- a/translated/tech/20190416 Can schools be agile.md +++ b/published/20190416 Can schools be agile.md @@ -1,15 +1,16 @@ [#]: collector: (lujun9972) [#]: translator: (chen-ni) -[#]: reviewer: ( ) -[#]: publisher: ( ) -[#]: url: ( ) +[#]: reviewer: (wxy) +[#]: publisher: (wxy) +[#]: url: (https://linux.cn/article-11076-1.html) [#]: subject: (Can schools be agile?) [#]: via: (https://opensource.com/open-organization/19/4/education-culture-agile) [#]: author: (Ben Owens https://opensource.com/users/engineerteacher/users/ke4qqq/users/n8chz/users/don-watkins) 学校可以变得敏捷吗? ====== -我们一定不会希望用商业的方式运作我们的学校 —— 但是更加注重持续改进的教育机构是可以让我们受益的。 +> 我们一定不会希望用商业的方式运作我们的学校 —— 但是更加注重持续改进的教育机构是可以让我们受益的。 + ![][1] 我们都有过那种感觉一件事情“似曾相识”的经历。在 1980 年代末期我经常会有这种感觉,那时候我刚刚进入工业领域不久。当时正赶上一波组织变革的热潮,美国制造业在尝试各种各样不同的模型,让企业领导、经理人和像我这样的工程师重新思考我们应该如何处理质量、成本、创新以及股东价值这样的问题。我们似乎每一年(有时候更加频繁)都需要通过学习一本书来找到让我们更精简、更扁平、更灵活以及更加能满足顾客需求的“最佳方案”。 @@ -24,7 +25,7 @@ 这种不断改进的文化氛围遇到的第一个阻碍是,教育界普遍不愿意从其它行业借鉴可以为自己所用的思想 —— 特别是来自商界的思想。第二个阻碍是,主导教育界的仍然是一种自上而下的、等级制度森严的领导模式。人们往往只能在小范围内讨论这种系统性的、持续的改进方案,比如包括校长、助理校长、学校监管人(LCTT 译注:美国地方政府下设的一种官职,每个学校监管人管理一定数量的学校,接受学校校长的汇报)等等在内的学校领导和区域领袖。但是一小群人的参与是远远不足以带来整个组织层面的文化改革的。 -在进一步展开观点之前,我想强调一下,上面所做的概括一定是存在例外情况 的(我自己就见到过很多),不过我觉得任何一个教育界的利益相关者都应该会同意以下两点基本假设: +在进一步展开观点之前,我想强调一下,上面所做的概括一定是存在例外情况的(我自己就见到过很多),不过我觉得任何一个教育界的利益相关者都应该会同意以下两点基本假设: 1. 为学生提供高质量的、公平的教育和教学系统的工作所涉及到的任何人都应该将持续不断的改进作为思维方式里的重要部分; 2. 如果学校领导在做决策的时候可以更多地参考那些离学生最近的工作者的意见,那么学生以及学生所在的社区都将更加受益; @@ -37,12 +38,11 @@ 我并不是要呼吁大家像经营商业一样经营我们的学校。我所主张的是,用一种清晰而客观的态度去看待任何行业的任何思想,只要它们有可能帮助我们更好地迎合学生个体的需求。不过,如果想有效率地实现这个目标,我们需要仔细研究这个 100 多年来都停滞不前的领导结构。 - ### 把不断改进作为努力的目标 有一种说法认为教育和其它行业之间存在着巨大的差异,我虽然赞同这种说法,但同时也相信“重新思考组织和领导结构”这件事情对于任何一个希望对利益相关者负责(并且可以及时作出响应)的主体来说都是适用的。大多数其它行业都已经在重新审视它们传统的、封闭的、等级森严的结构,并且采用可以鼓励员工基于共有的优秀目标发挥自主性的组织结构 —— 这种组织结构对于不断改进来说十分关键。我们的学校和行政区是时候放开眼界了,而不应该拘泥于只听到来自内部的声音,因为它们的用意虽然是好的,但都没有脱离现有的范式。 -对于任何希望开始或者加速这个转变过程的学校,我推荐一本很好的书:Jim Whitehurst 的《开放的组织》(这不应该让你感到意外)。这本书不仅可以帮助我们理解教育者如何创造更加开放、覆盖面更广的领导领导结构 —— 在这样的结构下,互相尊重让人们可以基于实时数据作出更加灵活的决策 —— 并且它所使用的语言风格也和教育者们所习惯使用的奇怪的词汇库非常契合(这种词汇库简直是教育者们第二天性)。任何组织都可以借鉴开放组织的思维提供的实用主义方法让组织成员更加开放:分享想法和资源、拥抱以共同协作为核心的文化、通过快速制作原型来开发创新思维、基于价值(而不是提出者的职级)来评估一个想法,以及创造一种融入到组织 DNA 里的很强的社区观念。通过众包的方式,这样的开放组织不仅可以从组织内部,也能够从组织外部收集想法,创造一种可以让本地化的、以学生为中心的创新蓬勃发展的环境。 +对于任何希望开始或者加速这个转变过程的学校,我推荐一本很好的书:Jim Whitehurst 的《开放组织》(这不应该让你感到意外)。这本书不仅可以帮助我们理解教育者如何创造更加开放、覆盖面更广的领导领导结构 —— 在这样的结构下,互相尊重让人们可以基于实时数据作出更加灵活的决策 —— 并且它所使用的语言风格也和教育者们所习惯使用的奇怪的词汇库非常契合(这种词汇库简直是教育者们第二天性)。任何组织都可以借鉴开放组织的思维提供的实用主义方法让组织成员更加开放:分享想法和资源、拥抱以共同协作为核心的文化、通过快速制作原型来开发创新思维、基于价值(而不是提出者的职级)来评估一个想法,以及创造一种融入到组织 DNA 里的很强的社区观念。通过众包的方式,这样的开放组织不仅可以从组织内部,也能够从组织外部收集想法,创造一种可以让本地化的、以学生为中心的创新蓬勃发展的环境。 最重要的事情是:在快速变化的未来,我们在过去所做的事情不一定仍然适用了 —— 认清楚这一点对于创造一个不断改进的文化氛围是十分关键的。对于教育者来说,这意味着我们不能只是简单地依赖在针对工厂模型发展出来的解决方案和实践方式了。我们必须从其它行业(比如说非营利组织、军事、医疗以及商业 —— 没错,甚至是商业)里借鉴数不清的最佳方案,这样至少应该能让我们 *知道* 如何找到让学生受益最大的办法。从教育界传统的陈词滥调里超脱出来,才有机会拥有更广阔的视角。我们可以更好地顾全大局,用更客观地视角看待我们遇到的问题,同时也知道我们在什么方面已经做得很不错。 @@ -50,7 +50,6 @@ 坚持不懈地追求不断改进这件事情,不应该只局限于那种努力在一个全球化的、创新的经济环境中争取竞争力的机构,或者是负责运营学校的少数几个人。当机构里的每一个人都能不断思考怎样才能让今天比昨天做得更好的时候,这就是一个拥有优秀的文化氛围的机构。这种非常有注重协作性和创新的文化氛围,正是我们希望在这些负责改变年轻人命运的机构身上看到的。 - 我非常期待,有朝一日我能在学校里感受到这种精神,然后微笑着对自己说:“这种感觉多么似曾相识啊。” -------------------------------------------------------------------------------- @@ -60,7 +59,7 @@ via: https://opensource.com/open-organization/19/4/education-culture-agile 作者:[Ben Owens][a] 选题:[lujun9972][b] 译者:[chen-ni](https://github.com/chen-ni) -校对:[校对者ID](https://github.com/校对者ID) +校对:[wxy](https://github.com/wxy) 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出 diff --git a/sources/talk/20190630 Data Still Dominates.md b/sources/talk/20190630 Data Still Dominates.md new file mode 100644 index 0000000000..e9a86acf68 --- /dev/null +++ b/sources/talk/20190630 Data Still Dominates.md @@ -0,0 +1,100 @@ +[#]: collector: (lujun9972) +[#]: translator: ( ) +[#]: reviewer: ( ) +[#]: publisher: ( ) +[#]: url: ( ) +[#]: subject: (Data Still Dominates) +[#]: via: (https://theartofmachinery.com/2019/06/30/data_still_dominates.html) +[#]: author: (Simon Arneaud https://theartofmachinery.com) + +Data Still Dominates +====== + +Here’s [a quote from Linus Torvalds in 2006][1]: + +> I’m a huge proponent of designing your code around the data, rather than the other way around, and I think it’s one of the reasons git has been fairly successful… I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships. + +Which sounds a lot like [Eric Raymond’s “Rule of Representation” from 2003][2]: + +> Fold knowledge into data, so program logic can be stupid and robust. + +Which was just his summary of ideas like [this one from Rob Pike in 1989][3]: + +> Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming. + +Which cites [Fred Brooks from 1975][4]: + +> ### Representation is the Essence of Programming +> +> Beyond craftmanship lies invention, and it is here that lean, spare, fast programs are born. Almost always these are the result of strategic breakthrough rather than tactical cleverness. Sometimes the strategic breakthrough will be a new algorithm, such as the Cooley-Tukey Fast Fourier Transform or the substitution of an n log n sort for an n2 set of comparisons. +> +> Much more often, strategic breakthrough will come from redoing the representation of the data or tables. This is where the heart of your program lies. Show me your flowcharts and conceal your tables, and I shall be continued to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious. + +So, smart people have been saying this again and again for nearly half a century: focus on the data first. But sometimes it feels like the most famous piece of smart programming advice that everyone forgets. + +Let me give some real examples. + +### The Highly Scalable System that Couldn’t + +This system was designed from the start to handle CPU-intensive loads with incredible scalability. Nothing was synchronous. Everything was done with callbacks, task queues and worker pools. + +But there were two problems: The first was that the “CPU-intensive load” turned out not to be that CPU-intensive after all — a single task took a few milliseconds at worst. So most of the architecture was doing more harm than good. The second problem was that although it sounded like a highly scalable distributed system, it wasn’t one — it only ran on one machine. Why? Because all communication between asynchronous components was done using files on the local filesystem, which was now the bottleneck for any scaling. The original design didn’t say much about data at all, except to advocate local files in the name of “simplicity”. Most of the document was about all the extra architecture that was “obviously” needed to handle the “CPU-intensiveness” of the load. + +### The Service-Oriented Architecture that was Still Data-Oriented + +This system followed a microservices design, made up of single-purpose apps with REST-style APIs. One component was a database that stored documents (basically responses to standard forms, and other electronic paperwork). Naturally it exposed an API for basic storage and retrieval, but pretty quickly there was a need for more complex search functionality. The designers felt that adding this search functionality to the existing document API would have gone against the principles of microservices design. They could talk about “search” as being a different kind of service from “get/put”, so their architecture shouldn’t couple them together. Besides, the tool they were planning to use for search indexing was separate from the database itself, so creating a new service made sense for implementation, too. + +In the end, a search API was created containing a search index that was essentially a duplicate of the data in the main database. This data was being updated dynamically, so any component that mutated document data through the main database API had to also update the search API. It’s impossible to do this with REST APIs without race conditions, so the two sets of data kept going out of sync every now and then, anyway. + +Despite what the architecture diagram promised, the two APIs were tightly coupled through their data dependencies. Later on it was recognised that the search index should be an implementation detail of a unified document service, and this made the system much more maintainable. “Do one thing” works at the data level, not the verb level. + +### The Fantastically Modular and Configurable Ball of Mud + +This system was a kind of automated deployment pipeline. The original designers wanted to make a tool that was flexible enough to solve deployment problems across the company. It was written as a set of pluggable components, with a configuration file system that not only configured the components, but acted as a [DSL][5] for programming how the components fitted into the pipeline. + +Fast forward a few years and it’s turned into “that program”. There was a long list of known bugs that no one was ever fixing. No one wanted to touch the code out of fear of breaking things. No one used any of the flexibility of the DSL. Everyone who used the program copy-pasted the same known-working configuration that everyone else used. + +What had gone wrong? Although the original design document used words like “modular”, “decoupled”, “extensible” and “configurable” a lot, it never said anything about data. So, data dependencies between components ended up being handled in an ad-hoc way using a globally shared blob of JSON. Over time, components made more and more undocumented assumptions about what was in or not in the JSON blob. Sure, the DSL allowed rearranging components into any order, but most configurations didn’t work. + +### Lessons + +I chose these three examples because they’re easy to explain, not to pick on others. I once tried to build a website, and failed trying to instead build some cringe-worthy XML database that didn’t even solve the data problems I had. Then there’s the project that turned into a broken mockery of half the functionality of `make`, again because I didn’t think about what I really needed. I wrote a post before based on a time I wrote [a castle-in-the-sky OOP class hierarchy that should have been encoded in data instead][6]. + +Update: + +Apparently many people still thought I wrote this to make fun of others. People who’ve actually worked with me will know I’m much more interested in the things I’m fixing than in blaming the people who did most of the work building them, but, okay, here’s what I think of the engineers involved. + +Honestly, the first example obviously happened because the designer was more interested in bringing a science project to work than in solving the problem at hand. Most of us have done that (mea culpa), but it’s really annoying to our colleagues who’ll probably have to help maintain them when we’re bored of them. If this sounds like you, please don’t get offended; please just stop. (I’d still rather work on the single-node distributed system than anything built around my “XML database”.) + +There’s nothing personal in the second example. Sometimes it feels like everyone is talking about how wonderful it is to split up services, but no one is talking about exactly when not to. People are learning the hard way all the time. + +The third example was actually from some of the smartest people I’ve ever had the chance to work with. + +(End update.) + +“Does this talk about the problems created by data?” turns out to be a pretty useful litmus test for good systems design. It’s also pretty handy for detecting false expert advice. The hard, messy systems design problems are data problems, so false experts love to ignore them. They’ll show you a wonderfully beautiful architecture, but without talking about what kind of data it’s appropriate for, and (crucially) what kind of data it isn’t. + +For example, a false expert might tell you that you should use a pub/sub system because pub/sub systems are loosely coupled, and loosely coupled components are more maintainable. That sounds nice and results in pretty diagrams, but it’s backwards thinking. Pub/sub doesn’t _make_ your components loosely coupled; pub/sub _is_ loosely coupled, which may or may not match your data needs. + +On the flip side, a well-designed data-oriented architecture goes a long way. Functional programming, service meshes, RPCs, design patterns, event loops, whatever, all have their merits, but personally I’ve seen tools like [boring old databases][7] be responsible for a lot more successfully shipped software. + +-------------------------------------------------------------------------------- + +via: https://theartofmachinery.com/2019/06/30/data_still_dominates.html + +作者:[Simon Arneaud][a] +选题:[lujun9972][b] +译者:[译者ID](https://github.com/译者ID) +校对:[校对者ID](https://github.com/校对者ID) + +本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出 + +[a]: https://theartofmachinery.com +[b]: https://github.com/lujun9972 +[1]: https://lwn.net/Articles/193245/ +[2]: http://www.catb.org/~esr/writings/taoup/html/ch01s06.html +[3]: http://doc.cat-v.org/bell_labs/pikestyle +[4]: https://archive.org/stream/mythicalmanmonth00fred/mythicalmanmonth00fred_djvu.txt +[5]: https://martinfowler.com/books/dsl.html +[6]: https://theartofmachinery.com/2016/06/21/code_vs_data.html +[7]: https://theartofmachinery.com/2017/10/28/rdbs_considered_useful.html diff --git a/sources/tech/20190510 Learn to change history with git rebase.md b/sources/tech/20190510 Learn to change history with git rebase.md index cf8f9351d9..4d46fef81f 100644 --- a/sources/tech/20190510 Learn to change history with git rebase.md +++ b/sources/tech/20190510 Learn to change history with git rebase.md @@ -1,5 +1,8 @@ +Translating by Scoutydren.... + + [#]: collector: (lujun9972) -[#]: translator: ( ) +[#]: translator: (Scoutydren) [#]: reviewer: ( ) [#]: publisher: ( ) [#]: url: ( ) diff --git a/sources/tech/20190625 The cost of JavaScript in 2019 - V8.md b/sources/tech/20190625 The cost of JavaScript in 2019 - V8.md new file mode 100644 index 0000000000..e21eefd5ad --- /dev/null +++ b/sources/tech/20190625 The cost of JavaScript in 2019 - V8.md @@ -0,0 +1,178 @@ +[#]: collector: (lujun9972) +[#]: translator: ( ) +[#]: reviewer: ( ) +[#]: publisher: ( ) +[#]: url: ( ) +[#]: subject: (The cost of JavaScript in 2019 · V8) +[#]: via: (https://v8.dev/blog/cost-of-javascript-2019) +[#]: author: (Addy Osmani https://twitter.com/addyosmani) + +The cost of JavaScript in 2019 · V8 +====== +**Note:** If you prefer watching a presentation over reading articles, then enjoy the video below! If not, skip the video and read on. + +[“The cost of JavaScript”][1] as presented by Addy Osmani at #PerfMatters Conference 2019. + +One large change to [the cost of JavaScript][2] over the last few years has been an improvement in how fast browsers can parse and compile script. **In 2019, the dominant costs of processing scripts are now download and CPU execution time.** + +User interaction can be delayed if the browser’s main thread is busy executing JavaScript, so optimizing bottlenecks with script execution time and network can be impactful. + +### Actionable high-level guidance # + +What does this mean for web developers? Parse & compile costs are **no longer as slow** as we once thought. The three things to focus on for JavaScript bundles are: + + * **Improve download time** + * Keep your JavaScript bundles small, especially for mobile devices. Small bundles improve download speeds, lower memory usage, and reduce CPU costs. + * Avoid having just a single large bundle; if a bundle exceeds ~50–100 kB, split it up into separate smaller bundles. (With HTTP/2 multiplexing, multiple request and response messages can be in flight at the same time, reducing the overhead of additional requests.) + * On mobile you’ll want to ship much less especially because of network speeds, but also to keep plain memory usage low. + * **Improve execution time** + * Avoid [Long Tasks][3] that can keep the main thread busy and can push out how soon pages are interactive. Post-download, script execution time is now a dominant cost. + * **Avoid large inline scripts** (as they’re still parsed and compiled on the main thread). A good rule of thumb is: if the script is over 1 kB, avoid inlining it (also because 1 kB is when [code caching][4] kicks in for external scripts). + + + +### Why does download and execution time matter? # + +Why is it important to optimize download and execution times? Download times are critical for low-end networks. Despite the growth in 4G (and even 5G) across the world, our [effective connection types][5] remain inconsistent with many of us running into speeds that feel like 3G (or worse) when we’re on the go. + +JavaScript execution time is important for phones with slow CPUs. Due to differences in CPU, GPU, and thermal throttling, there are huge disparities between the performance of high-end and low-end phones. This matters for the performance of JavaScript, as execution is CPU-bound. + +In fact, of the total time a page spends loading in a browser like Chrome, anywhere up to 30% of that time can be spent in JavaScript execution. Below is a page load from a site with a pretty typical workload (Reddit.com) on a high-end desktop machine:![][6]JavaScript processing represents 10–30% of time spent in V8 during page load. + +On mobile, it takes 3–4× longer for a median phone (Moto G4) to execute Reddit’s JavaScript compared to a high-end device (Pixel 3), and over 6× as long on a low-end device (the <$100 Alcatel 1X):![][7]The cost of Reddit’s JavaScript across a few different device classes (low-end, average, and high-end) + +**Note:** Reddit has different experiences for desktop and mobile web, and so the MacBook Pro results cannot be compared to the other results. + +When you’re trying to optimize JavaScript execution time, keep an eye out for [Long Tasks][8] that might be monopolizing the UI thread for long periods of time. These can block critical tasks from executing even if the page looks visually ready. Break these up into smaller tasks. By splitting up your code and prioritizing the order in which it is loaded, you can get pages interactive faster and hopefully have lower input latency.![][9]Long tasks monopolize the main thread. You should break them up. + +### What has V8 done to improve parse/compile? # + +Raw JavaScript parsing speed in V8 has increased 2× since Chrome 60. At the same time, raw parse (and compile) cost has become less visible/important due to other optimization work in Chrome that parallelizes it. + +V8 has reduced the amount of parsing and compilation work on the main thread by an average of 40% (e.g. 46% on Facebook, 62% on Pinterest) with the highest improvement being 81% (YouTube), by parsing and compiling on a worker thread. This is in addition to the existing off-main-thread streaming parse/compile.![][10]V8 parse times across different versions + +We can also visualize the CPU time impact of these changes across different versions of V8 across Chrome releases. In the same amount of time it took Chrome 61 to parse Facebook’s JS, Chrome 75 can now parse both Facebook’s JS AND 6 times Twitter’s JS.![][11]In the time it took Chrome 61 to parse Facebook’s JS, Chrome 75 can now parse both Facebook’s JS and 6 times Twitter’s JS. + +Let’s dive into how these changes were unlocked. In short, script resources can be streaming-parsed and-compiled on a worker thread, meaning: + + * V8 can parse+compile JavaScript without blocking the main thread. + * Streaming starts once the full HTML parser encounters a `