人在情绪高涨的时候，看什么都顺眼，做什么都顺手；人在情绪低落的时候，做什么都不顺手，做什么都别扭。
人们只要想着成功，成功的景象就会出现在心中。
新思想只有在真正相信它、对它着迷的人手中，才可以开怀结果。
平时表现良好，但因为没有足够的心理准备而在关键比赛场合失败的现象。
每个人都不能同时挑选两种或两种以上的行为准则或者目标信念，否则他的工作和生活很快就会陷入混乱。
我们今天的选择将决定我们三年后的生活，什么样的选择会产生什么样的结果。
当一个人对某一特定目标的追求进行到一半时，通常会对自己能否完成最终目标而产生怀疑，甚至对完成这一目标的意义产生怀疑。
执着能让我们获得更多的机会，执着能让我们的行为受到钦佩，执着能让我们距离成功更近一步。
事情如果有变坏的可能，不过这种可能性有多小，它总会发生，并造成最大可能的破坏。
期待机会，却又恐惧机会，对迎面而来的机会感到恐惧。
因失败而产生的绝望、抑郁和意志消沉。
每个人都不可能是全才，每个人都有其独特的优势和劣势，只要让一个人的优势得到充分的发挥，他一定能够取得惊人的成绩。
通常来说，在双方有共同利益的时候，人们都会优先选择竞争，而不是选择对双方都有利的合作。
人们第一次与某物或某人接触时会给对方留下深刻的印象。
人与人相遇靠的是一点缘分，人与人相处靠的则是一份诚意。
南风法则也叫温暖法则，它源于法国作家拉·封丹的一则寓言：南风的温暖比北风的凌冽更容易让人脱下大衣。
在人们的交际过程中，如果彼此间存在着某种共同之处或者相似的地方，那么双方就更容易互相接近，也更容易萌生亲密感。
一个人往往会因为有些小小的缺点，而显得更加可敬可爱。
良好的人际关系是在双方间自我爆率逐渐增加的过程中发展起来的。
同情容易引起好感
人们对自己的关注大多胜于他人，所以如果你想进入他人的世界，获得他人的认可，就要学会关注他人。
要让对方高一些，就必须使自己低一些；要让自己高一些，就必须使对方低一些。
见面频率低的朋友远不如见面频率高的朋友间的情谊深。
刺猬彼此靠近取暖，但是距离太近又会被刺痛。
一个人若是接受了他人提出的一个小要求后，他会更容易接受后续更高的要求。
沉默可以给人一种特别的压力，让对方望而却步，从而在适当的时候化解矛盾和冲突。
先提出一个大要求，在被拒绝之后，再提出小要求，小要求被接受的可能性更高。
站在对方的立场上去体验和思考问题。
人们一旦被贴上某种标签，就会成为标签所标定的人。
强者不一定是胜利者，但胜利迟早都属于那些有信心的人。
全面认识自己，知己知彼，摆脱盲从的误区。
人们识记一系列事物时，通常末尾部分形成的记忆最强烈。
人们一旦选择进入某一路径，无论这一路径是好是坏，惯性的力量会使这一选择不断自我强化，让其轻易走不出去。
人们在刚刚步入某一领域时，常常在一段时间内完全被置于自生自灭的状态下。
在心中梳理某方面的榜样有助于我们梳理正确的人生理想。
同样一杯温水，如果摸之前先摸了冷水，会觉得更热；如果摸之前先摸了热水，会觉得更冷。
没有什么比市区热忱更使人觉得垂垂老矣。精神状态不佳，一切都将处于不佳状态。
第一天的工作没有做完，在休息时间，也会出现心里紧张状态。
不知道从何下手的事情，搁置一段时间后会忽然茅塞顿开。
温水煮青蛙，安逸不仅能让我们忽略周围环境的变化，还会让我们失去很多机会。
如果水平不够提前升值，容易出现：
因为可以从华盛顿大学食堂看到雷尼尔山峰，教授们就算工资低一些也愿意在这里工作。
胜利需求、安全需求、归属与爱的需求、尊重需求、自我实现需求。
刻板效应又叫定型效应，道听途说或者先入为主的想法都会使你的认知与真实情况产生极大的偏差。因此，经常与下属沟通至关重要。
多看事情的正面，不断的表扬，会使人进步更快。
向一个人传递积极的期望，他就会进步得更快，发展得更好。
成就需要、权利需要、友谊需要。
鲶鱼会捕食沙丁鱼，在沙丁鱼的鱼槽中放入一条鲶鱼，会使沙丁鱼保持活力。
因为有压力，所以有动力。
热炉效应形象地阐述了企业的惩处原则，即警告性原则、一致性原则、及时性原则、公平性原则。
有时管理人员越多，工作效率反而越差。
在处理一件事时，如果要求多个个体共同完成，每个个体的责任感就会变弱，也叫做旁观者效应。
Suppose that Alice is transferring 8 bitcoins to Bob, the process goes like this:
In order to achieve a successful bitcoin transaction, the following five key technologies are needed:
Bitcoin network does not have a central server. It is composed of many full nodes and light nodes. Among them:
Compared to traditional centralized transaction system, the Bitcoin uses a distributed ledger in which users open “accounts,” strictly speaking, addresses. Everyone can set up an “account” on the bitcoin blockchain and get a pair of a public key and a private key. The address is the hash value of the public key. We interact with the address through the private key.
Each of us has a wallet, which stores a private key. When two people transfer bitcoin to each other, they can do it directly through their wallet software.
Here, the decentralization of bitcoin is reflected in the fact that there is no longer a centralized organization for centralized management of ledgers. The account books are stored in the decentralized network composed of many nodes; there is no longer a centralized organization to help us manage accounts and deal with transactions. Everyone manages their own wallets, and the transactions are recorded by the distributed account books.
Some people will ask whether the bitcoin in our address is recorded in the account book or whether there seems to be a “centre” to store our assets. In fact, this ledger is stored in the decentralized network in a distributed way, so from this perspective, it can be seen as decentralized.
In contrast, for centralized online payment systems, centralized servers usually manage centralized ledgers. For the bitcoin system, the system behind it is a decentralized network, and network nodes jointly maintain a distributed ledger.
(to be continued)
Here we illustrate it by means of comparison.
There have always been three forms of “currency” in the digital world:
Comparison of three forms and cash in the physical world:
| Cash in physical world | Centralized e-cash | Centralized computer points | Decentralized e-cash | |
|---|---|---|---|---|
| Issuance | Centralized | Centralized | Centralized | Decentralized |
| Transaction | Decentralized | Centralized | Centralized | Decentralized |
The relationship between three forms and cash in the physical world:
| Cash in physical world | Centralized e-cash | Centralized computer points | Decentralized e-cash | |
|---|---|---|---|---|
| Map physical currency? | / | Yes | No | No |
| Self-issue? | / | No | Yes | Yes |
From the shallower to the deeper, it has the following aspects:
Later, in the process of developing and applying blockchain technology, we have to adjust from the most extreme ideal state to the practical direction.
Most blockchain projects are now managed by foundations. For example, Ethereum is co-ordinated between founder Vitalik Butlin and the Ethereum foundation, rather than being fully autonomous as the bitcoin community.
Main design principles of blockchain system:
Four key features by William Mougayar:
What bitcoin needs to do is a “point-to-point e-cash system”, in which the sender and the receiver deal directly without the intervention of intermediaries.
In order to remove the trusted third party and other intermediaries, we need to solve the “double blossom problem”. In the summary, Nakamoto presents a point-to-point network solution, and introduces the core of the solution - blockchain. He didn’t mention the word block chain, but in the paper he mentioned the two concepts of block and chain respectively.
The blockchain of bitcoin is a data block with time stamp and data storage and a chain connected by hash pointer based on workload proof.
This chain, or ledger, is stored on nodes of bitcoin network in a distributed way, so it is also called distributed ledger.
Nodes in bitcoin network perform encryption hash calculation according to rules to compete for the right to generate new blocks. After the node wins the competition, it gets the bookkeeping right. When it generates a block and becomes the latest block, it gets the mining reward corresponding to the new block.
Workload proof is also the security mechanism of blockchain account book. This chain cannot be modified without redoing the large amount of calculation required by “proof of workload”, which ensures the reliability of the data on the blockchain.
At any moment, the longest chain is the final record accepted by all.
Since the longest chain is completed by the main computing power in the network, as long as they do not cooperate with attackers, the longest chain they generate is reliable. This principle is called the “longest chain principle”.
Bitcoin’s decentralized network architecture is very simple and requires very little infrastructure. It can run on the Internet network. Computer nodes can leave or join the decentralized network at any time. When they join, they only need to follow the longest chain principle.
reference:
http://c.biancheng.net/view/1889.html
In the digital world, if we want to create a disintermediated and decentralized “e-cash”, we also need to design a complete financial system.
This system should be able to solve a series of problems as follows:
To solve the problems, Nakamoto developed Bitcoin system, which consists of 3 layers:
In the design of bitcoin system, Nakamoto creatively combines computer computing power competition with economic incentives to form a proof of work (POW) consensus mechanism, which enables mining computer nodes to complete the function of currency issuance and accounting in the calculation competition, as well as the operation and maintenance of blockchain ledger and decentralized network.
This forms a complete cycle: the mining machine mining (calculation power competition), the completion of decentralized accounting (operation system), and the economic incentive (economic reward) in the form of bitcoin.
Bitcoin’s workload proof consensus mechanism is a connecting layer, connecting the upper application and the lower technology: the upper layer is the issuance, transfer and anti-counterfeiting of e-cash; the lower layer is the node to the central network to reach an agreement and update the distributed ledger.
Blockchain is the technology of “value representation” and “value transfer” in the digital world. One side of blockchain coin is the encrypted digital currency or token representing value, and the other side is the distributed ledger and decentralized network for value transfer.
Blockchain is an underlying technology derived from bitcoin. In other words, bitcoin is the first successful application of blockchain technology.
When people talk about Blockchain, what do they mean:
When referring to blockchain, ordinary people often refers to the fourth largest scope, namely “account book + Network + protocol + currency”. In the industry, when people refer to blockchain, they usually refer to the third scope, namely “account book + Network + Protocol”. When talking about blockchain, many software developers usually refer to the second range of “ledger + network”.
reference:
http://c.biancheng.net/view/1884.html
An evaluation index system refers to an organic whole with an internal structure composed of multiple indicators that characterize various aspects of the evaluation object and their interconnections.
In order to make the indicator system scientific and standardized, the following principles should be followed when constructing it:
And the constructed index system should possess these features:
3E theory refers to:
3E system represents the trend of diversified development of performance evaluation system. Through the establishment of 3E standard system, the soft environment evaluation system is more scientific and transparent, and the efficiency and operability of performance evaluation are increased, which greatly promotes the improvement and development of public policy evaluation system.
reference:
https://www.researchgate.net/profile/Francisco_Ruiz14/publication/220831115_Quality_Assessment_of_Business_Process_Models_Based_on_Thresholds/links/5473100f0cf216f8cfae97f4.pdf
author:
Laura Sánchez-González, Félix García, Jan Mendling, Francisco Ruiz
Institution:
Grupo Alarcos, Universidad de Castilla La Mancha
Humboldt-Universität zu Berlin
Process improvement is recognized as the main benefit of process modelling initiatives. Quality considerations are important when conducting a process modelling project. While the early stage of business process design might not be the most expensive ones, they tend to have the highest impact on the benefits and costs of the implemented business processes. In this context, quality assurance of the models has become a significant objective.
The aim of our empirical research approach is to validate the connections between an extensive set of metrics (number of nodes, diameter, density, coefficient of connectivity, average gateway degree, maximum gateway degree, separability, sequentiality, depth, gateway mismatch, gateway heterogeneity, cyclicity and concurrency) and the ease with which business process models can be understood (understandability) and modified (modifiability).
The structural metrics apparently seem to be closely connected with understandability and modifiability.
After analyzing which measures are most useful, it is interesting to know what values of these measures indicate poor quality in models. That means, thresholds values could be used as an alarm of detecting low-quality structures in conceptual models.
The strength of the correlation of structural metrics with different quality aspects clearly shows the potential of these metrics to accurately capture aspects closely connected with actual usage.
写年度报告也好，写普通报告也好，如果能够掌握一些技巧的话，就可以给自己的报告增色不少。
有一些数据，直接拿出来并不好看。然而如果把这些绝对值转化成相对值，比如百分比、环比、增长率等，事情就大不一样。
例子：
| 实际情况 | 报告内容 |
|---|---|
| 组内5个人，只有1个评了A | 组内有20%的员工拿了A |
| 去年销售额占总公司1%，今年1.1% | 销售额环比增长10% |
| 去年一共接了2个订单，今年还没做完 | 客户存留率100% |
| 去年一共接了2个订单，今年还没做完，又接了2单 | 全年订单数量翻番 |
有的数据已经不错了，但是老板总觉得不够好。这个时候，就需要把这些数据进行模糊化。
例子
| 实际情况 | 报告内容 |
|---|---|
| 去年销售额占总公司1%，今年1.1% | 销售额实现两位数增长 |
| 去年一共接了2个订单，今年还没做完，又接了2单 | 订单数量增长速度极快 |
汇报的时候，老板通常会更在意比较“差”的部分，而这些也会直接影响你的最终评估结果。但是一年发生了这么多事情，不可能事事顺心，都表现的很好。因此需要把分散的值，整合起来。
例子：
| 实际情况 | 报告内容 |
|---|---|
| 今年前边11个月销售额都环比增长10%，12月圣诞活动没搞好环比下降了5% | 年销售额增长5% |
| 组内销售任务每人10w，1人6w，4人12w | 组内销售任务超额完成 |
有些时候，无论怎么整合，这些数据就是不好看。这个时候，需要在报告的数据前边加上定语，对数据进行过滤。
例子：
| 实际情况 | 报告内容 |
|---|---|
| 游戏运营，玩家总数少了10w | 新增玩家50w（流失60w就不说了） |
| 新兴领域，一共10家公司 | 在领域内进入国内前10 |
无论怎么套路，没做就是没做，多少就是多少，实事求是不扯谎，这是底线。
本文只是给大家提供一些年度报告的包装思路，往坏了说算是歪门邪道，充其量可以帮助大家临时抱抱佛脚。
巧妇难为无米之炊，最重要的还是平时下足功夫。把工作做好，对自己、对别人都是负责。
多一些真诚，少一些套路。
reference:
https://e-archivo.uc3m.es/bitstream/handle/10016/27943/how_MOBICOM_2018_ps.pdf?sequence=1
author:
Cristina Marquez, Marco Gramaglia, Marco Fiore, Alert Banchs, Xavier Costa-Perez
Institution:
Universidad Carlos III Madrid
CNR-IEIIT (Institute of Electronics, Computer and Telecommunication Engineering, the National Research Council of Italy)
NEC Laboratories Europe
Network slicing has profound implications on resource management, as it entails an inherent trade-off between:
(i) the need for fully dedicated resources to support service customization, and
(ii) the dynamic resource sharing among services to increase resource efficiency and cost-effectiveness of the system.
While the technology needed to support this paradigm is well understood from a system standpoint, its implications in terms of efficiency are still unclear.
In this paper, we fill such a gap via an empirical study of resource management efficiency in network slicing.
Building on substantial measurement data collected in an operational mobile network
(i) we quantify the efficiency gap introduced by non-reconfigurable allocation strategies of different kinds of resources, from radio access to the core of the network, and
(ii) we quantify the advantages of their dynamic orchestration at different timescales.
Our results provide insights on the achievable efficiency of network slicing architectures, their dimensioning, and their interplay with resource management algorithms.
Current trends in mobile networks point towards a strong diversification of services, which are characterized by increasingly heterogeneous Key Performance Indicator (KPI) and Quality of Service (QoS) requirements.
current mobile network architectures lack the necessary flexibility to meet the ex- treme requirements imposed by such services.
The agenda for 5G networks is to achieve this mainly via network virtualization, which evolves the traditional hardbox paradigm into a cloudified architecture where the once hardware-based network functions are implemented as software Virtual Network Functions (VNFs) running on a general-purpose telco-cloud. Network virtualization enables the deployment of multiple virtual instances of the complete network, named network slices.
Network slicing strategies. Deeper slices (A to E) reserve resources to services across a wider portion of the end-to-end network architecture, but reduce the space for unconstrained resource sharing.
When instantiating a slice, an operator needs to allocate sufficient computational and communication resources to its VNFs. In some cases, these resources may be dedicated, be- coming inaccessible to other slices. Alternatively,
(i) service customization, which favours the deployment of specialized slices with tailored functions for each service and, possibly, dedicated and guaranteed resources;
(ii) resource management efficiency, which increases by dynamically shar- ing the resources of the common infrastructure among the different services and slices; and,
(iii) system complexity, resulting from deploying more dynamic resource allocation mechanisms that provide higher efficiency at the cost of em- ploying elaborate operation and maintenance functions.
From a system standpoint, the technology needed to support the different types of slices is well understood or even already available.
Our aim is to shed light on the trade-offs between customization, efficiency, and complexity in network slicing, by evaluating the impact of resource allocation dynamics at different network points. Based on our analysis, it is thus possible to determine in which cases the gains in efficiency are worth the sacrifice in customization/isolation and/or the extra complexity. Since resource management efficiency in network slicing highly depends on the traffic patterns of different services supported by the various slices, we build on substantial service-level measurement data collected by a major operator in a production mobile network, and:
(i) quantify the price paid in efficiency when suitable algorithms for dynamic resource allocation are not available, and the operator has to resort to physical network duplication;
(ii) evaluate the impact of sharing resources at different
locations of the network, including the cloudified core, the virtualized radio access, or the individual antennas;
(iii) outline the benefit of dynamic resource allocation
at different timescales, i.e., allowing to reallocate resources across slices with different reconfiguration intervals
The operator owning the infrastructure implements slices $s \in S$ , each dedicated to a different subset of services. Every network level $\ell$ is composed by a set $C_{\ell}$ of network nodes.
model the mobile network architecture as a hierarchy composed by a fixed number of levels ( $\ell=1, \ldots, L$ ) ordered from the most distributed ( $\ell=1$ ) to the most centralized ( $\ell=L$ )
Denote a slice specification as:
$$
\mathbb{Z}=(f, w)
$$
involves:
(i) Guaranteed time fraction $f$ : the operator engages to guarantee that the traffic demand of the slice is fully serviced during at least a fraction $f \in[0,1]$ of time.
(ii) Averaging window length w: the operator commitment on fraction f above is intended on discrete-time demands of granularity w, with traffic averaged over the disjoint time windows of duration w.
average load over window k covering a time interval of the same name with duration w:
$$
\bar{o} _ {c,s} (k)=\frac{1}{w}\int_{k}o_{c, s}(t)\mathrm{d}t
$$
the amount of resources allocated to slice s at node c during window k:
$$
r_{c, s}^{\mathbb{Z}}(k)
$$
Let $F _ {s, c, n} ^ {w}$ be the Cumulative Distribution Function (CDF)
of the demand for slice s at node c during reconfiguration period k, averaged over windows of length w: then, the minimum $\hat{r} _ {c, s} ^ {\mathbb{Z}} (n)$
that satisfies Equation (1) can be computed as $\hat{r} _ {c, s} ^ {\mathbb{Z}} (n)=\left(F_{s, c, n}^{w}\right)^{-1}(f)$ .
$$
\mathbb{R} _ {\ell, \tau} ^ {\mathbb{Z}} = \sum _ {s \in \mathcal{S}} \sum _ {\mathcal{C} \in C _ {\ell}} \sum_{n \in \mathcal{T}} \tau \cdot \hat{r} _ {c, s} ^ {\mathbb{Z}} (n)
$$
The above equation represents the total amount of resources needed to meet slice specifications, under the possibility of dynamically re-configuring the allocation with periodicity $\tau$ .
In perfect sharing, the allocated resources correspond to those required when there is no isolation among different services, hence traffic multiplexing is maximum. Formally,
$$
\mathbb{P} _ {\ell, \tau} ^ {\mathbb{Z}} = \sum _ {c \in C_{\ell}} \sum _ {n \in \mathcal{T}} \tau \cdot \hat{r} _ {c} ^ {\mathbb{Z}} (n)
$$
Multiplexing efficiency as the ratio between the resources required with network slicing and those needed under perfect sharing:
$$
\mathbb{B} _ {\ell, \tau} ^ {\mathbb{Z}} = \mathbb{R} _ {\ell, \tau} ^ {\mathbb{Z}} / \mathbb{P} _ {\ell, \tau} ^ {\mathbb{Z}}
$$
Our two reference urban regions are a large metropolis of
several millions of inhabitants, and a typical medium-sized city with a population of around 500,000, both situated in Europe. Service-level measurement data was collected in the target areas by a major operator with a national market share of around 30%. We leverage these real-world traffic demands to define network slices. Details are in Section 3.1.
On top of this, we model the hierarchical network infrastructures in the target regions by assuming that the operator deploys level- $\ell$ nodes so as to balance the offered load among them. This is discussed in Section 3.2.
We organise our evaluation as follows. First, we investigate worst-case settings where very stringent slice specifications are enforced, and no dynamic reconfiguration of resources is possible (Section 4.1). We then relax these constraints, and assess efficiency as slice specifications are softened (Section 4.2), or in presence of periodic resource orchestration (Section 4.3). Finally, we evaluate the impact of varied slice configurations (Section 4.4), and of a resource assignment accounting for instantaneous traffic demands (Section 4.5).
Just use:
1 | pip install PyExecJS |
or
1 | pip3 install PyExecJS |