Digest | 项目工时评估技巧, Picoasso法则, 7个必知DB概念, Nuxt Image

Software Estimation Technique: Uncertainty+Complexity+Expected, Prolific output demands deliberate practice for as long as possible, Mathematics is the music of reason

>  2021年07月07日信息消化

### Nuxt Image is here! And it's a game changer

[Nuxt Image is here! And it's a game changer](https://www.netlify.com/blog/2021/06/11/nuxt-image-is-here-and-its-a-game-changer/)

##### Nuxt Image

[Nuxt Image](https://image.nuxtjs.org/) is a plug-and-play image optimization module designed to give developers access to powerful components that will make image optimization a natural part of your workflow. But don’t take my word for it, let me show you just how powerful it is.

Using [Nuxt Image](https://image.nuxtjs.org/), once we upload our `space.jpeg` image into our `static` directory, all we need to do to solve this is call our image with the `nuxt-img` component.

```html
<nuxt-img
  src="/img/space.jpg"
  alt="Space by Jeremy Thomas on Unsplash"
  sizes="xl:100vw lg:100vw md:100vw sm:100vw xs:100vw"
/>
```

When our site is built, this is what [Nuxt](https://nuxtjs.org/) will basically generate all of the assets we need as well as the following HTML.

```html
<img
  src="/_nuxt/image/space-61b74b.jpg"
  alt="Space by Jeremy Thomas on Unsplash"
  sizes="(max-width: 320px) 100vw, (max-width: 640px) 100vw, (max-width: 768px) 100vw, (max-width: 1024px) 100vw, 100vw"
  srcset="
    /_nuxt/image/space-f4d5ae.jpg  320w,
    /_nuxt/image/space-c1b4a0.jpg  640w,
    /_nuxt/image/space-71cff9.jpg  768w,
    /_nuxt/image/space-38eb82.jpg 1024w,
    /_nuxt/image/space-61b74b.jpg 1280w
  "
/>
```

### The Picasso Principle — Habits of Highly Prolific Minds

原文：[The Picasso Principle — Habits of Highly Prolific Minds](https://medium.com/personal-growth/the-picasso-principle-habits-of-highly-prolific-minds-99d63df9a6e4)

Prolific minds keep on giving. Their creative outputs are sometimes beyond comprehension. Many of the world’s best creatives are insanely prolific.

Picasso created 50,000 works of art in his life. He used to paint till 2 am. “**Painting is just another way of keeping a diary.**” Pablo Picasso said. That mindset can set you up to become a better version of your creative self every day for a very long time.

Picasso devoted his life to art. Every idea had to be captured on canvas. He painted without holding back for years. He was committed to consistent creation. “Action is the foundational key to all success.” He said.

Picasso is not the only highly prolific creator. Many others came before and after him. Thomas Edison is known to have [acquired](https://www.history.com/topics/inventions/thomas-edison) 1,093 patents over his lifetime. He was an inventor, manufacturer and businessman.

Mozart composed over 600 pieces in his lifetime. Isaac Asimov wrote about 500 books in his lifetime.

Barbara Cortland published about 723 novels. “When she died a year later there were 160 unpublished novels still waiting to be published,” [writes](https://medium.com/the-mission/how-did-picasso-create-50-000-works-of-art-a3bc21e82c89) James Altucher.

Seth Godin has published over 7000 posts. He has been publishing a post every day for over a decade. He is also the author of 17 bestselling books.

How do prolific creators maintain their momentum for so long? **They commit an insane amount of time to their work** without holding back.

“I wake at five in the morning. I get to work as early as I can. I work as long as I can. I do this every day of the week, including holidays.” Isaac Asimov [said](https://fs.blog/2016/03/prolific-mr-asimov/). To be prolific, he [says](https://www.depauw.edu/sfs/interviews/asimov41interview.htm), you must be **a “singleminded, driven, nonstop person.”**

**Prolific output demands deliberate practice for as long as possible**. There is no way around it. It requires you to create, design, produce, invent, code, draw, write or publish daily or weekly. That’s how you become better.

Cal Newport says, “**Until you become good, you don’t have leverage.”**

### Software Estimation Is Hard. Do It Anyway.

原文：[Software Estimation Is Hard. Do It Anyway.](https://jacobian.org/2021/may/20/estimation/)

[One study by HBR](https://hbr.org/2011/09/why-your-it-project-may-be-riskier-than-you-think) found that one in six IT projects had cost overruns of over 200% and were late by almost 70%. [Another study by McKinsey](https://www.mckinsey.com/business-functions/mckinsey-digital/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value#) found that IT projects are on average 45% over budget and 7% over schedule.

They found large software projects were particularly bad: software projects with budgets over $15M went over budget by an overage of 66% and had schedule overruns averaging 33%.

Estimating a software project seems to always run up against [Hofstadter’s Law](https://en.wikipedia.org/wiki/Hofstadter's_law): “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

Unfortunately, it’s common to look at this pattern, see that estimating software project timelines is hard and just … give up. There’s an established “No Estimates” position that says we should entirely stop giving estimates on software projects. Many Agile methodologies involve arbitrary scoring systems – story points, t-shirt sizing, etc. – deliberately designed to help avoid giving estimates in time-scale units.

. In particular, “no estimates”-style project management can lead to better conversations about timelines: these systems encourage questions like “**what can we get done in the next two weeks?**” instead of “**how long will Feature X take?**” This can often be a much better way of thinking about software projects, especially long-lived ones.

**One major “secret” to advancing in a technical career is learning how to give accurate estimates**. It certainly has been for me: I don’t shy away from giving timelines, and I’ve learned how to be right often enough that folks trust my estimates.

And it *is* a skill: **estimation can be learned**: whatever technique you use, practice makes perfect. you’ll find which areas of your codebase are quick and easy to modify and which require more time; you’ll learn to recognize your own biases and where you’re most likely to over- or under-estimate.

### My Software Estimation Technique

原文：[My Software Estimation Technique](https://jacobian.org/2021/may/25/my-estimation-technique/)

##### The critical characteristic: capture time *and* uncertainty

##### My technique

My technique is this:

1. [Break down work](https://jacobian.org/2021/may/25/my-estimation-technique/#1-break-down-the-work) into less-complex tasks
2. [Estimate uncertainty](https://jacobian.org/2021/may/25/my-estimation-technique/#2-estimate-uncertainty)
3. [Do the math](https://jacobian.org/2021/may/25/my-estimation-technique/#3-do-the-math) to get expected- and worst-case estimates
4. [Refine](https://jacobian.org/2021/may/25/my-estimation-technique/#4-refine-if-necessary), if needed
5. [Track your accuracy](https://jacobian.org/2021/may/25/my-estimation-technique/#5-track-your-accuracy-so-you-can-improve-over-time), so you can improve over time

###### 1. Break down the work into less complex tasks

To some degree these names and numbers are arbitrary (though, you should pick a scale and stick with it long-term so that you can [get better over time](https://jacobian.org/2021/may/25/my-estimation-technique/#5-track-your-accuracy-so-you-can-improve-over-time)). They map well to the way I think about work, but different time scales would work just fine. Story points instead of labels work too; the names don’t matter. It *is* critical to use real wall-clock time, which means:

2. ###### Estimate uncertainty

| Uncertainty Level | Multiplier |
| :---------------- | :--------- |
| low               | 1.1        |
| moderate          | 1.5        |
| high              | 2.0        |
| extreme           | 5.0        |

###### 3. Do the math

###### 5. Track your accuracy, so you can improve over time

##### Other Estimation Techniques

- [Program Evaluation and Review Technique](https://www.techrepublic.com/blog/it-consultant/use-pert-technique-for-more-accurate-estimates/): PERT is a system that’s very close to the one I’ve presented above. PERT asks you to make three estimates: pessimistic (`P`), optimistic (`O`), and most likely (`M`). Then, you calculate a PERT estimate with the formula `(O + 4M + P) / 6`. I’ve never tried PERT – as I wrote above, I don’t much see the point in best-case estimates – but it seems good.
- [Evidence-based scheduling](https://www.joelonsoftware.com/2007/10/26/evidence-based-scheduling/) takes a radically different approach to estimation. Instead of starting with estimates, you start with work: dive in without an estimate at first, and track tasks/stories, their sizes, and how long they _actually__ take as you go. Over time, you can then apply the observed times from past stories to your remaining backlog, and an estimate naturally reveals itself.
- [Fruit-salad scrum](https://fberriman.com/2020/01/22/fruit-salad-a-scrum-estimation-scale/) is a somewhat silly alternative to story points or t-shirt sizes. But if you look past the jokes, it captures something that neither points nor shirt sizes do: it also captures uncertainty! It does this with a single axis: complexity and uncertainty both increase as the fruit gets bigger (i.e. the ???? watermelon is a task that’s large *and* uncertain). This is a shortcut, but one that frequently works. All you have to do to get time estimates out of fruit salad is map each fruit to a complexity/uncertainty pair, and then do the math as above. I’ve done this; it’s pretty accurate. And don’t underestimate the value of injecting a little bit of levity into something tedious like estimating.

### 7 Database Concepts You Should Know About

原文：[7 Database Concepts You Should Know About](https://betterprogramming.pub/7-database-concepts-you-should-know-about-a6825f46e449)

##### Databases Store Transactions — Not State (Kind Of)

Databases, or rather their internal architecture, aren’t very intuitive. You might think that a database is simply a data file or two and some code that manages connections and modifications to that data file. And you would be right to a certain extent. But really, at its core, a database is just a log file. This log file is a list of transactions that have been submitted to the database kept in the order in which they were submitted.
Everything else (the state of your tables, rows, schemas, etc.) is emergent from the accumulated changes recorded on this log. Each database engine stores this log a different way, but a section pseudo-log might look something like this:

```log
...
2021-06-07 12:24:35.044513-4000 INSERT INTO 'People' "jeff" "wilson"
2021-06-07 12:25:33.232098-4000 INSERT INTO 'People' "mike" "lou"
2021-06-07 12:25:37.140013-4000 INSERT INTO 'People' "pat" "cat"
2021-06-07 12:26:11.030002-4000 INSERT INTO 'People' "mark" "wilson"
...
```

From this log, a database can rebuild its tables, databases, schemas, and everything else if the data files are somehow corrupted. But there’s one very important caveat: Once a transaction is committed or rolled back, it is removed from the log. The purpose of the log is to stage changes until a transaction is completed — not to act as a sort of backup mechanism. Somewhat small and insignificant blips in the database can be recovered from the log, but anything more serious than a blip will call for some kind of external backup to be restored.
In PostgreSQL and some other relational databases, this log is called the Write-Ahead-Log (WAL). Managing this WAL and its various features is a big part of performance-tuning these databases and also how PostgreSQL manages replication. Any transaction that is written to the WAL is also broadcast to its replication peers so they can add the transaction to their WAL.
Understanding this mechanism is key to understanding how databases work and troubleshooting them when things go bad.
数据库，或者说它们的内部结构，并不是很直观的。你可能认为数据库只是一个或两个数据文件和一些管理数据文件的连接和修改的代码。在某种程度上你是对的。但实际上，在其核心部分，数据库只是一个日志文件。这个日志文件是一个已经提交给数据库的事务的列表，按照它们提交的顺序保存。
其他的一切（你的表、行、模式等的状态）都是由记录在这个日志上的累积变化而产生的。每个数据库引擎都以不同的方式存储这个日志，但是一个部分的伪日志可能看起来像这样。
从这个日志中，如果数据文件以某种方式被破坏，数据库可以重建它的表、数据库、模式和其他一切。但是有一个非常重要的注意事项：一旦一个事务被提交或回滚，它就会从日志中删除。日志的目的是在事务完成之前对变化进行分级，而不是充当一种备份机制。数据库中一些小的和不重要的突发事件可以从日志中恢复，但是任何比突发事件更严重的事件都需要某种外部备份来恢复。
在PostgreSQL和其他一些关系型数据库中，这个日志被称为Write-Ahead-Log（WAL）。管理这个WAL及其各种功能是调整这些数据库性能的一个重要部分，也是PostgreSQL管理复制的方式。任何被写入WAL的事务也会被广播给它的复制对等体，以便它们可以将该事务添加到它们的WAL中。
理解这个机制是理解数据库如何工作以及在出现问题时排除故障的关键。

##### NoSQL Doesn’t Replace SQL, It Complements It

The debate about using a SQL or NoSQL database will go on forever. I get that. But often missed in this argument is the fact that NoSQL databases don’t *replace* SQL databases. They *complement* them.

There are some things that NoSQL databases do very well and there are some things that SQL databases do very well. Prometheus is very good at storing time-series data like metrics, but you wouldn’t want to use MySQL for that. Is it technically possible? Yes, but it's not designed for that and you’re not going to get the best performance or developer experience out of it. On the flip side, you wouldn’t want to use Redis to store highly relational data like user accounts or financial transactions for the same reasons. Sure, you could make it work in the code, but why add that complexity and headache when you could just use the right tool for the job?

There is going to be some inevitable overlap in some areas. There are some excellent databases that are *technically* NoSQL that do a good job of storing relational data (see: Couchbase), but there are other outside factors that go into using one over the other. Factors like client language support, operational tooling, cloud support, and others are all things to take into account when choosing a database.

关于使用SQL或NoSQL数据库的辩论将永远持续下去。我明白这一点。但在这场争论中经常忽略的一个事实是，NoSQL数据库并没有取代SQL数据库。它们是对它们的补充。
有一些事情NoSQL数据库做得非常好，也有一些事情SQL数据库做得非常好。普罗米修斯在存储时间序列数据方面非常好，比如指标，但你不会想用MySQL来做这个。这在技术上是否可行？是的，但它不是为此而设计的，你不会从中得到最好的性能或开发者体验。反过来说，出于同样的原因，你也不会想用Redis来存储高度关系型数据，比如用户账户或金融交易。当然，你可以让它在代码中工作，但如果你可以使用正确的工具来完成这项工作，为什么还要增加这种复杂性和头痛呢？
在某些领域会有一些不可避免的重叠。有一些在技术上属于NoSQL的优秀数据库在存储关系型数据方面做得很好（见：Couchbase），但在使用其中一种时，还有其他外部因素。客户端语言支持、操作工具、云支持等因素都是选择数据库时需要考虑的因素。

##### Indexes Are Like Magic Until They're Not

Indexes are arguably one of the most important aspects of databases, yet they are often one of the most overlooked. An index, simply put, is a table of contents for the database when looking up data. Instead of having to scan an entire column looking for a single value, an index can tell it where that value is so the database engine can jump to it immediately.
If you’re reading this and saying to yourself, “Hey, this sounds like a hash table,” well, you’re not wrong. Indexes are basically a type of hash table for a given column in a table. Most relational databases automatically create an index on the primary key, but you can add indexes to as many columns as you wish.
But please don’t do this.
While indexes can speed up your read times significantly — especially in large datasets — they come with a trade-off when writing data to a table. Every time the table is updated, the indexes on that table also need to be updated, which adds extra time to each write transaction. This is because of what an index actually is. **Unlike a book’s table of contents that is simply a list of pointers, an index actually contains a second copy of the necessary columns just stored in a different order.** This means that indexes use a proportional amount of disk space and require I/O when being updated. When dealing with only a few indexes on a table, the trade-off is usually negligible, but any more than a few and your transactions start incurring the write penalty of having to update all of those indexes on every transaction.
This is why it is important to be strategic about where and when you use an index. The best way to decide whether or not to index a column is to take a hard look at your application, see what kinds of queries are most often used, and base your decision on that. Also, tools like application performance monitoring or database monitoring can help unearth any queries that might be improved with the addition of an index by tracking transaction times for the various database queries.

索引可以说是数据库最重要的方面之一，但它们往往是最被忽视的方面之一。简单地说，索引是数据库查找数据时的一个目录。与其要扫描整个列来寻找一个单一的值，索引可以告诉它这个值在哪里，所以数据库引擎可以立即跳到它。
如果你读到这里，对自己说，"嘿，这听起来像一个哈希表，"那么，你没有错。索引基本上是表内某一列的哈希表的一种类型。大多数关系型数据库会自动在主键上创建一个索引，但你可以根据自己的意愿为许多列添加索引。
但请不要这样做。
虽然索引可以大大加快你的读取时间--特别是在大型数据集中--但在向表中写入数据时，它们也是有代价的。每当表被更新时，该表的索引也需要被更新，这给每个写事务增加了额外的时间。这是因为索引实际上是什么。不像一本书的目录只是一个指针列表，索引实际上包含了必要列的第二个副本，只是以不同的顺序存储。这意味着索引使用了相应数量的磁盘空间，并且在更新时需要I/O。当在一个表上只处理几个索引时，这种权衡通常是可以忽略不计的，但如果超过几个，你的事务就会开始招致写入惩罚，即在每个事务中都要更新所有这些索引。
这就是为什么对你使用索引的地点和时间要有策略。决定是否为某一列建立索引的最好方法是认真审视你的应用程序，看看哪些类型的查询是最常用的，并以此为基础做出决定。另外，像应用程序性能监控或数据库监控这样的工具可以通过跟踪各种数据库查询的交易时间，帮助发现任何可能通过添加索引而得到改善的查询。

##### Scaling Is Hard

Databases present a unique challenge when it comes to trying to scale them. Because they store state and are therefore inherently stateful applications, finding ways to replicate that state across multiple database instances in a way that is consistent, safe, and fast enough to be transparent to any application is hard. This is why the most common way of scaling databases — especially relational databases — is with vertical scaling.
Let’s pause and take a minute to talk about the two kinds of scale: vertical and horizontal. To understand each method properly would take an entire article of its own (not a bad idea, actually…), but for now, we can break this down fairly simply. I think the best way I can explain this is with an analogy, so here goes: Let's say that you have a one-gallon jug of water, but it's got a small hole in it, so you need to move the water to another container. However, all you have are smaller containers that are less than one gallon. You could use two methods:
Use a high number of smaller containers (like drinking glasses) and distribute the gallon of water across those many containers.
Use a low number of one-quart containers and distribute the water over those few larger ones.
Using many smaller containers is horizontal scaling, where the workload (or water) is spread across many smaller containers. Using a few larger containers is vertical scaling, where the load is spread across a small number of large containers. With horizontal scaling, when you need to add additional capacity, you add more containers. With vertical scaling, you increase the few containers you already have.
With databases, the common practice is to vertically scale your database instances by adding CPU and RAM capacity. This avoids the issue of having to replicate state across a high number of instances but still allows your database to take on the extra load.
Some databases — especially NoSQL databases — can be massively horizontally scaled, but they usually come with a trade-off in consistency. These databases tend to be eventually consistent, where the data will eventually become consistent across the entire cluster, but replication may not be transparent to any applications accessing that data. That is, an application reading from database node A will get one version of the data, where an application reading from node D will get another version until the cluster can update that data on all nodes. While this might sound like a deal-breaker, if you design and build your applications with this in mind, it doesn’t have to be an issue.

当涉及到试图扩展数据库时，数据库提出了一个独特的挑战。因为它们存储状态，因此本质上是有状态的应用，找到在多个数据库实例中复制该状态的方法，而且是一致的、安全的、快速的，对任何应用都是透明的，是很难的。这就是为什么扩展数据库--尤其是关系型数据库--的最常见方式是垂直扩展。
让我们暂停一下，花一分钟来谈谈两种扩展方式：垂直和水平。要正确理解每一种方法，需要自己写一整篇文章（实际上，这不是一个坏主意......），但现在，我们可以相当简单地将其分解。我想我能解释这个问题的最好方式是打一个比方，所以就这样。比方说，你有一个一加仑的水壶，但它有一个小洞，所以你需要把水移到另一个容器。然而，你所拥有的都是小于一加仑的小容器。你可以使用两种方法。
使用大量较小的容器（如饮料杯），将一加仑的水分配到这些众多的容器中。
使用数量较少的一夸脱容器，将水分配到那几个较大的容器中。
使用许多较小的容器是横向扩展，工作量（或水）被分散到许多较小的容器中。使用几个较大的容器是垂直扩展，即把负载分散到少数大容器中。通过水平扩展，当你需要增加额外的容量时，你可以增加更多的容器。通过垂直扩展，你增加你已经拥有的几个容器。
对于数据库，通常的做法是通过增加CPU和RAM容量来垂直扩展你的数据库实例。这避免了必须在大量实例之间复制状态的问题，但仍然允许你的数据库承担额外的负载。
一些数据库--尤其是NoSQL数据库--可以进行大规模的横向扩展，但它们通常会在一致性方面进行折衷。这些数据库往往是最终一致的，数据最终会在整个集群中变得一致，但复制可能对任何访问该数据的应用程序不透明。也就是说，从数据库节点A读取的应用程序将得到一个版本的数据，而从节点D读取的应用程序将得到另一个版本，直到集群能够在所有节点上更新这些数据。虽然这听起来像是一个破绽，但如果你在设计和构建你的应用程序时考虑到这一点，它就不一定是一个问题。

### 一点收获

- “Mathematics is the music of reason”

~James Joseph Sylvester, English mathematician.

[Algebra is More Beautiful Than You Think](https://medium.com/the-wisest-friends/algebra-is-more-beautiful-than-you-think-73f1a13bec8b)