定投中的额外资金

一直基金定投 假设每个月$500 但现在突然有$6000额外闲钱 那应该是最近随便找个时间一笔投入 还是分12个月定投 我知道对于真正超长线的投资 两种完全没有区别 只是忍不住想知道最优解。

我觉得应该前者更优,理由有二:

1. 既然定投了,又何必time the market

2. 按复利算,早投早超生。可以外推,例如不是12个月,而是分12年,那明显是前者更优,区别还是有的。

[Notes] GraphQL vs. REST: What you didn’t know

The focus with GraphQL is more on how data is queried and less on how resources are modeled.

To start with, a GraphQL query could map to many different resolving functions, any of which could fail. As a result, a response could be partially successful and partially failed at the same time.

This vulnerability exists with other servers as well, but in the case of a GraphQL server, your API schema may expose potentially complex and expensive query patterns that could bring down your system easily.

[Notes] The Little Things That Make Employees Feel Appreciated

The trick is to avoid giving both types of feedback at once. When managers try the common sandwich technique, stuffing negative feedback between two layers of positive feedback, employees just get confused. In our experience, the people who needed the developmental feedback most tended to only hear the positive things their manager said, and the people who performed well left remembering more of the negative comments. So be sure to clearly separate out the positive feedback from the developmental feedback.

Instead of using sandwich, a better way is use your own failure story to start the conversation on improvement feedback. Bottom line is, you can only effectively deliver the improvement feedback after you gained the full trust.

[Notes] The No Code Delusion

Many businesses fail attempting to do digital transformation to access these benefits. The downside of trying to make this jump is that suddenly you’re becoming, at least in part, a software development company. Surprise: most companies are not good at this! A software environment is one of infinite possibility because most everything is achievable, with enough resource (time, money, people).

But the representation of the logic doesn’t reduce the fundamental complexity of the thing that it describes. In the same I way I can write “two” and “2” and mean the same thing, there are many ways of writing out business logic.

That means no code is possible if the end result involves no logic or just simple logic. At the same time, if logic is not heavily involved then that wouldn’t be the software system that the company is looking for so badly, and won’t be able to get away from being democratized.

as an example, you can define extremely complex software in Salesforce Cloud, without having to write a single line of code. It’s a mix of visual programming, basic rule setting and configuration.

With “no code”, it tends to be difficult or impossible to have a non-production environment. Even if you do have one, accurately copying changes over from one to the other is non-trivial. Salesforce has some excellent tooling available to make this work, and even in that environment it’s extremely difficult to do.

There are many tools which, while not “no code” per se, also allow users to produce more technical output. My favourite example is Looker, the business intelligence tool, but there are many such in different niches. As an aside on Looker: I find it extremely interesting that a lot of the model development in that environment happens in plain text, using regular software development tooling. I think this is one of the reasons it has ended up being successful.