Recently in 闲谈 Category

除了consolas之外,又发现俩好看的编程字体

Adobe的Source Code Pro https://github.com/adobe-fonts/source-code-pro

mononoki https://github.com/madmalik/mononoki

clink-gow

| No Comments | No TrackBacks

CLink - Bash Style Line Editing for cmd.exe 

Gow - Lightweight alternative to Cygwin

几个矩阵运算库

| No Comments | No TrackBacks

Armadillo http://arma.sourceforge.net/

Eigen http://eigen.tuxfamily.org/

已加电,设备管理器中可以识别,驱动自动识别且安装正常, 属性中提示"Windows cannot start this hardware device because its configuration information (in the registry) is incomplete or damaged. To fix this problem you should uninstall and then reinstall the hardware device. (Code 19)"

解决方式:

http://www.pchell.com/hardware/cd_drive_error_code_19.shtml

http://support.microsoft.com/kb/929461

http://technet.microsoft.com/en-us/library/cc772156%28v=ws.10%29.aspx

http://blogs.msdn.com/b/usbcoreblog/archive/2013/12/10/help-after-installing-windows-8-1-my-device-fails-with-error-code-19.aspx

理论上,所有程序都是等价的。基于lambda演算的函数式和基于图灵机的过程式都是等价的。那为啥还会有汇编,C,Python这么多语言?
那是不是大家直接在图灵机层面写机器码?把LISP去掉宏直接用lambda写code?

我自己的理解,所谓语言,本质是服务于人机交互的目的。人机交互的核心问题是人脑能理解的东西和带宽都是相当有限的。因此语言,本质上就是一套抽象规则,核心目的是把信息量提升到人能读写的程度。所以衡量语言优劣的核心问题,是提升信噪比的问题。

在满足这一前提的情况下,再尽量减少规则的数量,实现小内核,提升规则的正交性等目的,来方便使得语言易于学习和理解;最后才是提升语言本身的运行性能。所以这套规则是不是严格正交的,是否无冗余之类的完美性问题,都是相对次要的。

站在这个角度来说,语法糖当然是很有必要的东西,可以大大提升信噪比。只要别滥用语法糖,让语法糖本身成为噪音的一部分,就没啥理由去反对它。

Ben and I were discussing this thread, so we ended up writing a reply together.

This is an interesting discussion indeed, and we appreciate your interest in
learning more about the implementation of zookeeper. Here is another attempt to
explain you the differences between our algorithm and Paxos.

The Paxos Multi-Decree protocol basically consists of running parallel
instances of the Synod protocol (you probably know this one, but just for
completeness the paper is called "The Part-time parliament", and can be found
on Lamport's web page). The original Synod protocol, which is what we are
calling Paxos, proceeds in three phases, just like a three-phase commit
protocol. Our protocol instead, has only two phases, just like a two-phase
commit protocol. Of course, for Paxos, we can ignore the first phase in runs in
which we have a single proposer as we can run phase 1 for multiple instances at
a time, which is what Ben called previously Multi-Paxos, I believe. The trick
with skipping phase 1 is to deal with leader switching.

However, if we have a run with multiple proposers, operating simultaneously or
not, then we have to run phase 1 at least for the instances that haven't been
committed. The ZooKeeper protocol does not. The reason why we don't is
twofold. First, we assume FIFO channels. (FIFO meaning if a packet is received
from the channel all previously sent messages will have been delivered. If a
packet is lost in the channel, all subsequent packets will be lost. TCP is a
FIFO channel.) Paxos doesn't assume such a channel, and it is a rather
practical assumption that simplifies the protocol a lot. Second, there can be
at most one leader (proposer) at any time, and we guarantee this by making sure
that a quorum of replicas recognize the leader as a leader by committing to an
epoch change. This change in epoch also allows us to get unique zxids since the
epoch forms part of the zxid. Followers (they both acceptors and learners in
the Paxos terminology) have a FIFO
channel to a single leader, so that can only be a single active leader.

As a result, we can skip the phase 1 of Paxos completely, and also during
recovery we can skip all the uncommitted zxids of the epoch of the previous
leader. Since messages can be received out of order and even lost with Paxos,
it is possible to have gaps in the sequence of instances, and these instances
have to be decided when a new proposer arises. The conclusion is that by making
stronger assumptions for the system, we are able to use a simpler algorithm
that works truly in two phases.

One difference we find interesting is that Paxos embeds recovery into the
protocol. According to the algorithm, a new proposer just has to start one
phase 1 for each instance that it believes hasn't been committed yet. If such
an instance has been committed, then there is no problem as the value can't
change once it is committed. With the ZooKeeper protocol, we have to run an
auxiliary protocol to make sure that new leaders are up to date with respect to
operations that have been committed, but because of the FIFO assumption, we
know that the replica with the latest transaction id has the latest committed
state. Again, strengthening the assumptions for the system enable a simpler
solution.

Oh and don't get distracted by the leader election algorithm. Our protocol
assumes there is one, but it's not part of the broadcast protocol. The leader
election algorithm can easily change. There are actually two different ones in
the sources, and one of them doesn't even use notifications.

-Flavio and Ben

https://www.mail-archive.com/zookeeper-user@lists.sourceforge.net/msg00041.html

参考 Thoughts On Zookeeper 

在NoSQL存储系统选型中,有很多的维度可以区分系统给的特定优势所在,这里挑选几种维度介绍,注意不全面,也不是唯一的区分方式。没有哪种方案能够完 美的解决问题,重要的是正确的评估需求,然后做出明智的选择,有需要的话甚至可以采用混合使用的方案。对于一个问题,我们只有知道了有哪些可用的解决方 案,然后才能找到最合适解决该问题的方案。

1、数据模型

数据有多种存储的方式,包括键/值对(类似HashMap),半结构化的列式存储和文档结构存储。用户的应用如何存储数据?同时数据模式是否随着时间而变化?

2、存储模型

内存还是持久化?一旦考虑持久化存储,就需要考虑选择的方案是否会影响到访问模式。

3、一致性模型

严格一致性,还是最终一致性?一致性可能会影响操作延时,即系统响应读写请求的速度。

4、物理模型

分布式模式还是单机模式?系统的扩展性如何?

5、读/写性能

需要考虑自己的应用程序的访问模式,是读多写少,还是读写相当,或者写多读少?是用范围扫描数据好,还是用随机读请求数据更好?有些系统可能仅对这些情况中的一种支持的好。

6、辅助索引

辅助索引支持用户按不同的字段和排序方式来访问表。这个维度覆盖了某些完全没有辅助索引支持且不保证数据排序的系统(类似HashMap,即用户需要知道 数据对应键的值),到某些可能通过外部手段简单支持这些功能的系统。如果存储系统不提供这项功能,用户的应用可以应对或自己模拟辅助索引吗?

7、故障处理

机器会崩溃是一个客观存在的问题,需要有一套数据迁移方案来应对这种情况。每个数据存储如何进行服务故障处理?故障处理完毕之后是否可以正常工作?从一个正在提供服务的集群中卸载一台服务器时,也会遇到类似的问题。

8、压缩

需要存储TB级的数据时,尤其当这些数据差异性很小或由可读性文本组成时,压缩会带来非常好的效果。有些压缩算法可以将此类数据压缩到原始文件大小的十分之一。有可选择的压缩组件吗?又有哪些压缩算法可用?

9、负载均衡

加入用户有高读写吞吐率的需求,就要考虑配置一套能够随着负载变化自动均衡处理能力的系统。虽然这样不能完全解决这个问题,但是也可以帮助用户设计高读写吞吐量的程序。

10、原子操作的读-修改-写

RDBMS提供了很多这类的操作(因为它是一个集中式的面向单服务器的系统),但这些操作在分布式系统中较难实现,这些操作可以帮助用户避免多线程造成的资源竞争,也可以帮助用户完成无共享应用服务器的设计。有了这些比较并交换(compare and swap,CAS)操作,或者说检查并设置(check and set)操作,在设计系统的时候可以有效地降低客户端的复杂度。

11、加锁、等待和死锁

复杂的事务处理,如两阶段提交,会增加多个客户端竞争同一个资源的可能性。最糟糕的情况就是死锁,这种情况也很难解决。用户需要支持的系统采用哪种锁模型?这种锁模型能否避免等待和死锁?

 

参考资料:《HBase:权威指南》

架构师的要求

| No Comments | No TrackBacks

一个好的架构师至少要做到四点:

  1. 识别甚至提前预测到程序不同阶段的性能瓶颈,并以合理的代价消除。
  2. 识别束缚程序员生产力发展的瓶颈,并合理的消除。
  3. 解决组里面的尖端问题。
  4. 成为组员的精神支柱和旗帜。

他不应该:

  1. 总结需求。这是产品经理的事,除非他兼任。
  2. 评估工作时间,并保证工作进度。这是项目经理的事,除非他兼任。
  3. 召集,协调工作细节。这个随企业有不同划分,理论上是行政领导干的。有的企业是技术系的来做行政领导,有的是PM。
  4. 亲自写程序。除了初创,架构师亲自冲上去写大段大段的程序是找死的先兆。
  5. 预测技术的发展方向,并做出技术决策。您让TC干什么去?
  6. 政治斗争。架构师也来搞这个,要么被搞死,要么根本没心思做事。但是应该理解办公室政治,并且能够基本掌握情况。一点办公室政治都不懂的架构师肯定被搞死。

技术面试的四个点

| No Comments | No TrackBacks

1. 工程细节和技术细节

2. 技术原理和经验

3. 职位所需要做到最好的一个方面, 盯着问

4. 技术敏锐度和智商

About this Archive

This page is an archive of recent entries in the 闲谈 category.

Entertainment is the previous category.

google is the next category.

Find recent content on the main index or look in the archives to find all content.

Pages

OpenID accepted here Learn more about OpenID
Powered by Movable Type 5.2.7