Some reminiscences, some memories
Just another boring day

2009/06/30

SB玩家,大家围观

Filed under: My life — Tags: , — mikespook @ 09:35

别人发群上的,非常搞笑。转到这里,给大家围观一下……

/*—————————————————————–*/ (more…)

2009/06/29

Mysql 性能改进——最快实践

Filed under: Database — Tags: , , — mikespook @ 05:10

没错,标题我没打错。这里不是最佳实践,而是最快实践。在服务器上线,巨大的压力导致相应缓慢的时候,最佳实践已经毫无意义。这个时候,目的只有一个:最快改善性能,给开发人员重新设计、调整应用留出一定的时间。

这里不是细腻的微调,而是最粗旷的拉升。用最简单(可快速实施),变更最少(尽量避免变更引入新的 bug 和问题)的方法迅速改善 mysql 的性能。所以我这里的最快实践,不一定是最好的,不一定是最有效的,但是一定是最快能看到性能改善的方法。 (more…)

2009/06/25

关于这次广州地区网络通讯中断的猜想

Filed under: My life — mikespook @ 12:19

首先,写这篇东西的时候我是阴谋论者。其次,我现在已经因为不能正常上 gmail 收邮件和用 google 搜英文资料而七窍生烟。也就是说我现在处于精神异常状态。精神失常者不为自己的言行负责。

大家还都记得上次暴风影音导致网络瘫痪的事情吧?其实也怪不得暴风影音,只是有那么几台 dns 挂了,然后就向上查询,谁知道电信干线的 dns 还不如商业公司的免费服务器耐用,还没查就挂了。干线啊,干线挂了谁不受影响?

这次 google 被封了,当然天朝不是真的想干掉 google,所以也就是小小的教育一下,只从 DNS 解析在大局域网内禁用了 google。没想到邓爷爷的“从娃娃抓起”颇有成效,广大不明真相的群众学会了更改 DNS 的方式来绕过封锁,继续浏览和访问邪恶的 google。

天朝震惊,GFW怒了。

于是一大批 DNS 受到牵连,被干掉了。但是随之而来的问题是,一个 DNS 被干掉上万个查询被顶起。大家就相互查DNS吧,查啊,查啊,查不到……一不小心,干线上的设备就给查坏了。没错,就是这样,多脆弱啊,那当然了,要不然你以为真是 Matrix revolution 啊?

我又在扯淡了,干TND GFW……

PS: 经测试这两个 DNS 可用,包括 google 和 gmail 访问。

208.67.222.222
208.67.220.220

2009/06/21

PHP 5.3 RC4 发布

Filed under: PHP — mikespook @ 05:39

6月19日发布的PHP 5.3 RC4 同之前的RC版本并无很大出入,仅仅是修复bug和稳定性的改进。

新的一些特性,大家都讨论过了。不过我觉得还是有必要再罗嗦一下。 (more…)

2009/06/17

没有大团队——Nothing is big enough!

Filed under: My life — Tags: , — mikespook @ 05:38

刚才看到 Fenng 写的这篇博文:大技术团队的危险性。其中的一些东西,确实有一些感触。

维基百科上对于“团队”的定义是这样的(http://zh.wikipedia.org/wiki/%E5%9B%A2%E9%98%9F):

“团队由若干独立成员共同组建,有临时与长期之分。团队要为某一共同目标而奋斗,这需要团队成员贡献各自不同的专业特长。对团队的管理不同于上下级关系的管理,是横向的交流与沟通而不是纵向的命令与服从。”

虽然不是一个十分正式的定义,不过能说明几个问题。

  1. 团队不是一个人在战斗。
  2. 团队有统一的目标。
  3. 团队成员一定有分工。
  4. 团队的工作方式是合作的,而不是管制。

团队成员不光可以是个人,还可以是一个紧凑的组织,部门甚至公司。成员间进行平等的沟通、交流,相互支撑最终达到一个确定的、统一的目标。

由于沟通交流是平等的、横向的,那么就意味着任何沟通都是点对点的。当团队成员增加时,沟通的难度也就加大。

听起来有点像早期没有交换设备的点对点电话。在只有2个端点时有1条通信链路,3个端点就增加到3条,4个端点就增加到6条……那么对于一个有 n 个成员的团队,每个团队成员就需要有 n-1 个沟通链路。当沟通链路数足够大时,整个团队的人都在忙着沟通,而不是真正进行工作。当超过临界,沟通链路超过单个成员所能承受的极限时,为了维持团队正常的运作,有一些沟通链路会被忽略。一些工作关系相对疏远的成员不再进行沟通。这时从行政架构上虽然还是一个大团队,但是这个大团队已经不复存在,由若干个自然形成的小团队取而代之。

4-5个人组成了开发小组。4-5个开发小组组成了技术组。技术组、客服、市场……组成了项目组。项目1组、项目2组……组成了项目部……自最终稳定的团队结构是树形的,是分层的。站在每层去看,每层的团队都是小团队。当某一层上的团队开始有大团队出现时必然会有新的层次出现,将大团队重新划分为小团队。

这或许就是“无为而治”的道理吧。

硬是要将这种很有美感的、自然的组织架构重新排布,徒增本不需要的沟通链路,那么团队的结果或许跟瓦沙一样最终沉没。

2009/06/07

算数与数学

Filed under: My life — Tags: , — mikespook @ 14:43

只是灵感一发随手写点东西,所以不必太在意一些素材的来源和准确性。

先来看一个统计资料,据说中国学生的计算能力和对数字的敏感程度比国外学生普遍要高。然后有研究机构发表文章说因为汉语的数字都是单音节发音,更容易记忆和识别。当然,这个没错,五的确比 Five 好说出口,八比Eight明显容易听清。

在很早很早以前,大约“外国人还在树上当猴子的时候,中国人已经在研究勾股定理了。”这不是我说的,是我上小学的时候,给我们做数学启蒙的数学协会的会长讲的。虽然是个玩笑话,但是足以说明中国的算数在很早以前就有高度的发展。

自然辩证法的老师还说过,虽然中国的算数发展很高,但是遗憾的是没有能够归纳总结,上升到数学的高度来看问题。而近代科学的许多重要发展都是建立在数学体系的日趋完整上面。所以中国在近现代科学技术的发展总是难以突破。

综合上面的材料,我在上楼的时候突然有一个灵感。没有经过严格的证明和推敲,不过有点意思。

如果说中国的算数的发展和计算能力的突出是因为单音节的数字发音导致的。那么,止步不前在算数这一具体的领域,而没有演进成数学这一更加抽象理论或许也是这个容易识别的单音节造成的呢?因为数字的容易听读,注意力集中在具体的数字上而导致计算高度发达。但是正是由于过分关注数字,而没有进一步的抽象算数的发达就掩盖了本可以衍生出的抽象的、理论化的数学的产生。

相比西方,英语可能是还是数字发音相对简单的一种语言。德语、法语、拉丁语这些在数字表达上多少还有一些复杂的、特殊的东西。西方那些精通算数的人,或许就是因为这些数字发音太繁琐,交流很麻烦。就把数字抽象成一个一个的字母,而这些本是为了交流方便的字母的替换和抽象就今儿上升到一个体系化的、公式化的科学——数学就这么演进出来了。

其实,我是扯淡的……

2009/06/02

《围墙》——钱终输

Filed under: My life — Tags: — mikespook @ 13:55

序章:墙里的人想冲出去,墙外的人想挤进来……
PS:问候一下国外的友人:“今天你‘墙’了吗?”
话不多说,来张猛图的。别人没见过的,我亲自从德国带回来的……………

……………照片:
The wall

2009/05/22

在游戏中使用脚本语言

Filed under: Game, NetBeans — Tags: , , — mikespook @ 05:55

这只是一个有趣的探索,demo 使用 java 编写。模拟了一个龙与地下城类 RPG 游戏中,在不同的房间内移动的简单游戏场景。

阅读本文前,首先下载使用 Netbeans 6.5 建立的完整项目代码:下载。然后,我会用 UML 图的方式来说明如何在游戏中使用脚本,其中可能还会简介一下游戏中实体对象的建立和管理(不知道值得不值得另外写一篇文章来介绍了)。

I have a dream… (more…)

2009/05/18

服务器又休息了两天

Filed under: My life — Tags: , — mikespook @ 07:46

服务器又休息了两天,原因说出来很“囧”。xxiyy.com,就是我一直用的那个“沪ICP备05006454号”突然被查,说是没有备案。

不知道为什么,我手里有明明用了几年的备案号和那个 cert 备案证书,但是用备案号和域名都查不到备案的信息。而上星期我又将 xxiyy.com 从以前的服务器转到了这台服务器上,于是服务器就这么给封了两天。如果不转,我都不知道备案信息就这么人间蒸发了。

天朝要拿捏,我又能说什么呢?重新备过吧。想做个良民可真难!!!

不过话又说回来,想想人家窦娥。我只是蒸发了一个备案信息,服务器休息了两天而已。天朝没有把我也蒸发了是我莫大的荣幸,所以心里也特平衡了。

“向前进,向前进。备案的责任重,工信的冤仇深 ”

2009/05/12

MySQL InnoDB 隔离级别探索

Filed under: Database — Tags: , , , — mikespook @ 09:28

概述

本文会简单介绍 Mysql 使用的支持事务的存储引擎 InnoDB 的隔离级别,以及每个隔离级别下回产生的并发问题。同时为了更加深刻的理解 InnoDB 引擎的隔离级别,还会探讨如何通过加锁解决不同隔离级别下的并发问题。本文使用的实验环境是 mysql-5.1.33-win32,其他版本的 MySQL 可能会有不同。 (more…)

Newer Posts »

Powered by WordPress xxiyy.com 沪ICP备05006454号 mikespook.com 粤ICP备09065095号