今天看到每个研究生人手一本（正规应该是一本编了号不活页的本子，只允许删除不允许撕）的实验笔记本，其实是她们的实验手册。上面记着她们查文献查来的实验方案，和每次实验的数据。

今天总要内容是测DHA的产量。喜闻学姐用原来的培养基，生物量竟长到70多克，学姐看起来也很高兴的样子～
后来问，是因为把葡萄糖控制在不太高的浓度内，然后不停流加以防碳源不够（文献有说碳源浓度不能过高因此做此改进）。同时，学姐还改变了碳源和氮源的比，这两种因素加起来，其实也搞不清具体是哪一个因素起的作用。

DHA是产在细胞之内的。第一步先破细胞。
学姐说查过不少文献，要做到这一点有化学法、XX法、XX法等。DHA易于氧化，所以用真空的烘。
她认为这种方法比较适用于DHA提取。缺点是每次都会喷出来。
检测需要0.25克，一喷就0.16左右了。

称了烘后重，然后是各加1.5mL蒸馏水。
之后是各加2mL盐酸水解。
之后，是加正己烷，萃取，萃取液用液氮烘干。
之后，（由于我们实验室国产色谱仪不够稳定），往每个样里面加300块一克的相当纯的二十酸，作为参照，一起参加皂化等的反应，以便一起色谱，起参照作用。
再之后，我们就回去了，某丫头要赶六点的快船，就闪了。

听说原来有做实验不懂又不问，接果实验方案实验结果什么的全部是错的。嘻嘻，这么说我们要多问啦~
学姐说毕业了没人做这个课题了，我们要先专心努力加油考试，然后专心努力补基础，同时专心努力地叫学姐多教点~~呵呵

这一天终于体会
什么叫真正喜欢一个人

看着窗边水墨的景
宣纸上勾勒的远山似黛
柔波

原来被现实割裂得陆离死气的夜
灯光突然变得像星星
俯身下去
嗅着淡淡的体香
轻倚

我们披着星光
在这样一个美丽迷离的世界
传动

突然想作一首诗
只是那意境似远
朦胧

昨天请假了数码钢琴，去见卢老师。从此有了一段到晚上九点才结束的获益匪浅的时光。从专业学习到人性中正直真实和善良智慧的一面，我昨天享受了洗涤。不过卢老师见我来了一直说你要表回去，我说我都出来了还好意思回去，他说老师会感动的。我错了，嘻嘻。

就是专业中重要的是哪部份，终于有如计算机似的的类似了解。专业书继续看下去，我要懂得越来越多。
其实进了实验室以来，就越来越感到我们在化院的合理性，生化工程，莫说人家是化工与生物交叉的学科，就是生物本身，至今也是一直以化学为根基的。而且听听老师们讲讲关于挂课，请假这样让一些同学恨老师的东西，也就越发让人觉得，无谓抱怨是毫无思考和道理的东西。
卢老师说我们专业的骨干学科有，生物工艺原理之类（即发醇工程），代谢工程，生化分离工程（汗，不知漏了没），重要的主干课程有，分子生物，生物化学，生物化学实验，微生物学（好像有它，想过去也觉得是必要的，也不知道漏了没，到时候框架建立起来，便可以举一反三了）。
然后卢老师说姚老师是教计算机相关的好像是叫生化过程自动化技术的课，然后里面全是数学，主干是数值分析（^_^好熟悉的名字）。还有，那个写xmuruirjie的鱼一尾学长居然是他的研究生，做分子方向的，呵呵，还说下次要带来见见（Happy ing^_^）。
关于人性，人在死亡面前真实的恐惧和勇气，关于对GFW之类东西的BS（正如我那句话：我还是坚定的共产主义者没错，but my god，你在害怕什么），对于一个国家的政治和时局的真正透视，ME不仅又一次找到了共同点，感叹大家所见略同，而且，眼睛亮了很多，呵呵。这些感想还是记自己日记本里吧。

今天拉swgr入伙，被拒绝了。其实之于厦青，之所以我这种吊而郎当的人会进去，还一直想做个软件（现在还想）送给它以提升其影响力，原因便是厦青不够官僚。只有计较面子的时候才会计较一下官职，不过事后忘得很快，而且很多东西真的是应得的。现在被当成官僚分子给Decline了，呵呵。ME影响力不够，被人Decline那也是无可奈何的事情，努力就好咯。

选上了数码钢琴，发现弹琴如做实验，定要不功利无杂念，才看得见眼前的琴键，双手才听使唤。否则一不小心就乱弹琴了，双手也似技术引进一般。小时候一直没受到这方面的训练，现在接触，才发现访佛如灵魂净化一般。

昨日弹完一次合奏，我弹的和弦，但后面还是心急一赶，便什么也没有弹上，完全跟不上节拍。但弹完后，老师给我们放了一段关于钢琴的视频，说的英语，弹的两个高手像是日本还是韩国人。弹的内容，是一个众所周知的童话（不过我没听懂）。这时我发现书里面描述的那些关于音乐的东西，真正地向我走来了。

起初一段应该是序章，听不出它在弹些什么。而一段英文过后的第二章节，就可以明显听出在和弦里有一段比较像进行曲的旋律一直在重复，每一次重复，都要挑起人站起来踏上行军的步子走。这只是我的感觉，但后来那个卡通小解说员的动作，它看着自己的腿在不由自主地踏步。刚好证实了我的感觉。

后来玛丽似乎是行进路上碰到了些各种各样的人，有女巫、农夫和是稻草人之类的。后来是碰到了王子。只是对这些音乐，Me也比较感无知，完全是看解说猜的。

最后一段，解说里说到了王子和花的盛开，于是他们弹起来了。很梦幻和花繁储锦的感觉。两个弹琴的都是高手，手指飞快自如地移动，弹琴就像我们想剥个花生那样理说当然，手指时不时地在琴上画圆（以前听人说弹到这程度是高手），我想琴键一定全都在他们心中了。是两个人弹，但很多时候看着他们的手位根本分不清哪个是谁弹，只知道琴键在此起彼伏。

后来，我竟有了想睡的感觉，心里大叫糟糕，听这些东西怎么能睡。于是翻出某宫庭音乐家为了吵醒睡着观众而作的《惊鄂交响曲》，弹了几遍，没有睡着（其实就是一只手按几个键，完全初级的）。然而曲终之时，两位高手弹了最后几个音后戛然而止，节拍却是分毫不差。镜头扭转，那个小卡通人却已经呼呼大睡了。它被叫醒，然后解说，这曲子弹的是一场梦。

后记：原来一直不相信有《黑色星期五》这回事，如今看来，真正弹得好的音乐，恐怕真的对人有作用吧？此外，弹琴不只发现了脑袋空空心里平静的作用，发现了自己心理上的一个方面，也突然发现，键盘上只有这么几个键，但多个音一起弹成和弦，就变化无穷了（连我都对着曲谱弹出过进行曲的效果）。而且，如果弹的力度和手法适当，可以发出一些模拟现实的逼真的声音。这些真是太奇妙了。

• 关于组长
• 关于开发流程
• 关于技术实现

关于组长

1.组长感一
做View时候去原创做成了Model半成品。被很无情地说了一句：“再叫你做下去会误事”
很凭良心说，XQ对人客气的态度和方法，让人心存感激和不安，但有时候因为宽松，ME确实会偷懒；
这样被说后，很认真地开始整装上阵，然后心里愤愤不平——太不善于交流了他

2.组长感二
管理沟通中抓住人心的本领和严格把握进度的执行力让人很佩服，虽然心里想骂；
发现小组长并不能告诉我们具体要做什么，还听到一句相当经典的：“不做挨批，做了重改。你自己选”
当时实时记录的感想：
什么东西都是做了再说的，这里要说的便是：
在我们小组管理的时候，本身不懂技术是一个错。一个小组必须有一个技术骨干专门把握技术上的全局。
很让我佩服的长项，是他的超强的管理沟通和把握进度的能力;而他现在在我面前呈现的缺点便是：会做出错误决策，和可能造成成员抵触情绪（不懂怎么做，如何正确在细节上下令让别人做？古圣君贵无为而治，哪贵多管闲事？）
具体分析过来明显不过了：
1、CxRadio一开始的设计不明晰，不是先决定要做什么而是先看能否做;
对策：Design is more fun than debugging，设计上应越发巧妙越好，讨论好后再做;但这似乎又存在一个不能只想不做的问题。如果从这一方面来看，组长是对的，必须先让我们交半成品，随便我们改然后。一开始决不可能想那么清楚，也耽误事情;
2、不肯发挥成员的主动性;
对策：这一点，现在看来也不是问题好像。
看来这样管理是对的

3.组长感三
写在提交截止前一个星期.txt
原来所谓的CxRadio如此的简陋。
我在此组，此组却出了这样的垃圾，还与华丽的外表如此不衬，我怎么可以坐视呢？
我要写一个基本的可变动的框架，实现许多功能。
当今主要是在界面上。
对这个小组的后感，是起初那句，不懂技术的人不能直接领导技术人员，很显然非技术人员根本搞不清应该做些什么，还常常打压技术人员。
至少应该这样，一个善于管理和交流的人，直接领导一个技术人员，再由那个技术人员带领其它的技术人员。而那个会管理的，用他的管理才能，协助管理和沟通，即帮忙掌握进度，帮忙倾听组员等。
所谓善于交流，无非是了解大家各自的立场并沟通各自的感情使之不生误会。有时候甚至只需要倾听。始终交流失败，就应当考虑是否自己的决议本身存在问题。像那样辩论式的硬地灌输思想，不仅挫伤组员的积极主动和创造力，也无益于合作。
管理者不等同于策划者，他主要应该是交流，在大家有思想的时候要学会倾听，没有思想的时候才是一切自己做主。五个人毕竟比一个人聪明，组长凭什么以自己一人思想为中心滥改组员的劳动成果呢？
以上这些，也许对他而言，都可以用经验来弥补。
我不够同心，也是我个人的错误。祝福我们小组。去写框架实现吧
想做但无人需要.txt
我可能会觉得没有面子，我居然在这个队做出这样的东西。
但似乎从那一个角度去看，好像真的我功能多了也于事无补。
我就不适合被人管。
真希望自己另起炉灶。
他们不喜欢他，没想到到头来我亦是很不喜欢。
v2dot4观感.txt
看了V2.4，感觉真的好了很多。太好看了。
觉得好像还真的没有什么可做的了。
一路走来，觉得这个东西也很简单。没有什么难度，竟然不知道要往哪里提高才好。为什么我们不能自己做一些呢？(做一个软件送XQ的想法顿生)
这个设计显然是很成功的。
大家都未完成，拼的只是界面，和说明。而如今，我们的界面真的真的是太美了。原来觉得实在不完善，现在一看，却也很好的样子。
一开始的集中精力是对的。
看起来，某人真的很善于管理和激励。
现在已经用了从组长身上学来的管理办法正式开始计划送软件的事情了。现在便是应该回忆一下当时的开发流程，记录下来。
现在再回头看，当时自己心里主张的那个技术主干职能的人原来一直存在，就是我们的Big Blue同学。
于是感叹这次收获良多，其实从他身上可学的还有那种一下子能把握到任务要点的能力，辟如人家省级的创实，还有我们Radio的策划，是我自己开始发现，我们拼的便是界面和创意，这就完全回避了技术层面上不足的问题。界面，也不知道他哪里找来的这么强的人，创意，大家都没有功能实现，你怎么说就是什么，只要清晰漂亮有说服力。（不过会不会就买我们的帐呢。是真的技术上大家都未完成大家都有待改进...但又总不能坐视不管呢？肯定要开发出一些功能来的）

注一个疑问，就是在compound pattern那里，那个数duck的家伙说他可能会忘记数了没有，这个问题的解决方案是用工厂模式。不理解为什么一开始。后来发现，工厂模式在这里，就是代理生产，不用自己操心，自然也不会数错的意思而已（难道工厂模式的作用就是这个？）。

昨天夜里把仙四通关了。原来熬夜看MV没开音乐，有无音乐就是不一样啊。梦璃离去Me差点哭了，但真正感动的是玄霄对过去的回忆那一段和它的音乐（好像是寂难永劫的调子）。

觉得云一行人太过理想化了，有些悲伤看来觉得全无道理，似乎无什么好悲的，有些看法则十分消极。云傻子一行人揭开的上一代的恩怨，这个故事更加动人。

“昔日修炼双剑、苦无进境之时，无人让我放弃……初有所成、经络逆变之时，无人让我放弃……失却望舒、日夜受火焚之苦，无人顾我生死……如今，太迟了。”

这句是玄霄真正心境的表露了，放在剧末，个人觉得应是点睛吧。

“终我一生，成于修仙，毁于修仙，我已经没有退路了……”

它的第一章是系统清晰地说明了工程生产中存在许多无法理清的各种因素耦合交错作用。本书是想系统地从多个方面共同分析生化生产过程。

看了第二章，还在论述工程生产中的因素耦合的问题。

当一切终于落到自己的手中来决定的时候，我们是否真的像了解和关心自己这样来决断别人呢？其实只是求一个做人（注：不是那种道德修养类的）和无错罢了。

虽说做到的人不无道理，没做到的，一定公平吗？这又是怎么样一个是非因果呢？先公平后选人还是先选人后公平？单考虑一个因素觉得这是不公的吗？如果综观之，是否又公平恰好呢？存在就有它的道理嘛。

内定制的道理在于，上司往往最了解属下做了些什么。最不公平在于，能任职者是需要一段时间的事先培养的。

现在再想想，我们抓住机遇做应该做的事情就好了，表想太多。

>这本中文版是我认为意译（声明：我没翻译过）得十分生动的一版。在代理模式的首页的那幅图下面的引言一类的东西就可以看出。原>版英文好像用的是好警察坏警察一类的（从英文意思猜的），这里很生动地用了中文很传统的词：黑脸、白脸。这是否是一个英文口语>惯用法不得而知。看了英文书再看中文书每一次比较的共同感受：很生动很本土化很好懂。

>现在开始看书，写笔记：

现在是2008.4.9，离了很久呵呵
Proxy Pattern就没有认真看了。

其实个人觉得，它就是控制Access，类似于代理服务器，这个模式就是为了让本机的Java程序访问到更多的东西。当然也能够实现控制访问了（这两个图证明了这个个人观点）：

摘抄一下吧：
The Proxy Pattern provides a surrogate or placeholder for another object to control access to it.
它的图是这样的：

1. Introduction to Proxy Pattern
•  
2. 最基本的Proxy Pattern
• 
3. Proxy Pattern是可以用来控制访问的
• （就像这个经纪人）
• （控制访问的Proxy Pattern的图表）
• （具体实现的时候是这样的）

在Fireside Chats里它是和Decorator对话。确实制作一个替身假装真正访问的对像，来修饰访问的具体方法，就是Decorator的做法。
No new principles this chapter.

不知道为什么进入大学以来，一直有种头脑不够清楚的感觉，很多东西弄得我现在还有些迷糊。心理原因吧，以前的事情，过去很久了。Me要首先相信Me现在的状态是正确的。

申请的时候就发现了，我看计算机和软件相关的申请书完全看得懂，看自己专业完全看不懂。当时有计算机的学长劝我转系。

才知道他们软件学院申请到省级的项目，也就是一个比较大的校内资源搜索引擎。而组长为了把申请书写玄些，就叫组员们上网搜索尽量多的相关资料，结果写出来的申请书谁也看不懂（我也没看懂，这么不具体玩玄乎，像是科学精神吗真是的）；而计算机申请到省的吴振宇那队，也是自己的项目软件从高中便已经开始开发，答辩之后便能与我们说：“那老师这方面也懂不多，便没有多问”

到具体实施阶段，电脑开发软件都是不太需要设备的东西。他们的导师也忙，也没什么空管他们，他们却可以以请教之名请教老师具体过程，自己反正了解，一方面也先做。

这才是像样的组长。什么样的人负责可以从最大程度上影响那件事情的发展，一个了解负责有相应能力的组长方可带着一个组向好的方向发展。我什么都不懂，无法开始，不也就是我的错么？老师一开始给那些论文，如我们能借之了解整个流程，项目的具体步骤，细到真正知道要做什么，也就不至于现在做一个只会烦老师的人了。

……

后记

后来决定行动，写信给导师和两个学姐请求告知心目中的好书，并以少时学编程不成为例，证明指导是必要的，当年就看名词看不懂没学会，不知道学会的人说那其实是翻译问题。因而“至上大学，经人指导而后学会”

然而指导我的人如何学会？指导指导我的人的人又如何学会？如今知道道理，反推之，却发现有些东西，也不像所想的那样真的不懂名词就不懂。而且不论如何不懂，只要自信自己能学会，硬记下那些词耐心过一遍书，不行再过第二遍，反正那时的时间像海长，如何不会？再推之，人真的需要这么多指导么？自己如今受挫，是先定义了自己需要指导方可的。也因颇带急功近利之心做太多事情以致没有一件事情想清楚过。如今听那些导师照样很忙却也能四处找办法实施的人介绍经验，心想这是在情理之中的。然而当时倘若心里不服气，心想就算你最强的人最强能怎么怎么做，那岂有想不到的道理，不也就等同于今天听他们说么？倘若那时心里多存些思想，好好让自己静一静，就应该明白很多事情自己完全能做滴。

……

我们厦青上届主任QQ空间里最后一篇文章里有句话，说“不喜欢写Blog，因为它是写给别人看的，这样有些话就说不出来了”。觉得真是到点子上了。Me感觉她是一个感觉比较清楚的，即清楚知道自己在想什么的人，而且也是愿意像文学艺术那样追求梦中那种应该有的感觉的人。要忠于自己，便要感觉不到外界存在，排除一切干扰吧？我们前几天中午开会说要鼓励校园文艺创作，不然好像大学生只传播文化而不发扬。Me想，如要那样，像她那样的人，要多些吧？做到对自己的感觉敏锐，这种感觉对一些人来说，会不会有点遥远。比如Me？

PS:想让自己的BLOG服务风行的提供商们，建议要为自己的BLOG写一个本地张贴器。尤其是在网速还不够快的国家。

1. 自己的话：原来之所以叫作“具体数学”，是相对于“抽象数学”而言的。（怪我一理解什么是具体数学，然后就忘记了应该怎么表达了，反正书里很清楚）
2. 学习论据最好的方法是，通过自己的努力推导，而不是阅读别人的推导
3. 对于第一个发现错误者，不管是数学的错误，还是历史的错误或者印刷错误，将奖赏$2.56以示感谢。

这本英文原版的《深入浅出设计模式》快要到期了，在此之前想把其笔记上网完。个人无比赞美《量子物理史话》，也觉得书都应该写成Head First这样才是极好的。

初读此书关与别人讨论，他们说，这种东西看了易忘记，而且看着是一回事，实践是另一回事。这是我在完全没有实践基础的情况下理解的记录。力求用最简单的语言概括每章并且记录下自己的想法。之所以开始想写读书笔记，是因为某人的一句话让我觉得很有道理：读书笔记为了方便重读。想到自己看的书算是不少，可是当时的感觉，很多至今都没影了。没看书本身几乎不记得我看过。于是本人开始要写读书笔记了。为的是一个思想的延续。

以下是自己的看法：
对于模式，其实模式之所以存在，便要在一个的局限范围内才能成立，而模式又是为了加大代码适用的范围，其终极目标是要超越局限。这是一个很有意思的对立统一。而且，很多模式是从前面的模式和设计原则推导出来的。加上个人感觉，书在写到后面太多的，设计原则和模式的背后是本书不够抽象导致的。重复的意思一定很多，希望我在全部笔记归纳的时候能想通它的重复。

另外连书里也强调，模式在于去偶合改善设计方面，很多时候经验证实是有效的。然而能用简单的方法实现的时候就尽量不要用到模式，这一方面书上的说法是，模式它增加了代码量；而另一方面，究其实质，我觉得这是模式局限性的一种体现。即模式它不是一个很纯粹的降低复杂性的东西，它很多时候会导致问题。所以读者们不要患上模式病，写个排序都想起模式，说明您已经病了。

iterator，接触过OO的人都再熟悉不过了，在clients不了解细节的情况下为collections（就是一群随便什么东西）提供统一的transverse的接口。

（这里对client说几句。它是客户的意思。原来看编程书一看到“使用者”“客户”这样的生冷词语就不明所以。这是英文直译造成的。现在我替初学者说下，这里的客户指的是使用这段代码的人，大多数时候是程序员。）

composite呢，有一个很形象的比喻。我们用VB画界面的时候，上面的元素有Panel、Button、Frame、Text等等，其中Button和Text要放在Panel上，Panel又要放在Frame上才可以。它们之间有像树一样的包含的关系。然而显示是一样是要显示的。因而当我们在处理和遍历像这样的树形结构的东西时，就可以像这样。把节点和叶子都统一叫作component，然后有两个不同的子类nod和leaf。然后为二者实现不同的功能。在需要取得节点的孩子的孩子的时候，给节点和叶子不同的实现方法使之recursively transverse。设计中一个注意的问题是为了方便客户不要每次进行类型检查，给component类的每一种方法都throw UnsupportedOperationException。Caching的实现可能需要在遍历中用到，因为每次它都要遍历一遍、

OO Principles:A class should have only one reason to change
理解还不透。

Iterator:Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Composite:Compose objects into tree structures to represent part-whole hierarchies.Composite lets clients treat individual objects and compositions of objects uniformly.

英文不用解释了。

从名字上看就知道是提供接口用的。有一个图很形象地表达了这两个模式：

一个是沟通两者关系，一个是领导不同对象（比如一次一起关一台电视和CD机）。

OO Principles:Only talk to your friends.
在OO的世界中，只有一个朋友（意味着只与一个对象联系），可以使很多事情化复杂为简单（Decouple吧）。（譬如中国的人际关系网就比较复杂）

Adapter:Converts the interface of a class into another interface clients expect.Lets Classes work together that couldn't otherwise because of incompatible interfaces.

Facade:Provides a unified interface to a set of interfaces in a subsystem.Facade defines a higher-level interface that makes the subsystem easier to use.

英文即图形，没有什么好解释的了。

It's a great design tool for creating frameworks so that it's commonly found in the wild.

真的是一个很常见的模式。

OO principles:Don't call us,we'll call you.
即让call依赖于高抽象的类，减少耦合。

（关于偶合这个词，我想说的是，有多少中国人是一看这个词就明白它是什么意思的？应该看它的英文原意，即coupling，去偶合是decoupling。就是当每两件东西相互联系地太多，就像一团乱毛线，而进入的那种很不好拆开并且很不好增减的状态）

Template Method:define the skeleton of an algorithm in an operation,deferring some steps to subclasses.Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

其实也是在分离出变化的东西，然后让代码是那种组合式的，可以灵活更换部件及功能而不是死的。
例子：在排序中比较大小的时候，把确定一样东西究竟比另一样大还是小的代码换成object.compare();，然后给每个不同的具体类实现不同的compare方法。

遵循“把变化的东西分离出来”的design principle，对于区别在于类似于饮料之间添加剂的不同的东西，不用不同的类来区分不同的类而是用decorator pattern。

这个pattern是把每一个component分为Concrete Component和Decorator。其中Decorator要有与之对应的那一个concrete Component相关的接口和操作。到时客户就可以根据需要自由组合设计出需要的object，并且访问之。参考代码见书P95-98。

Java I/O就是Decorator Pattern应用的一个例子。图见P100。

OO Principles:Classes should be open for extension but closed for modification.
Decorator:Attach additional responsibilities to an object dynamically.Decorators provide a flexible alternative to subclassing for extending functionality.

Head First 里面的比喻是十分形象的，一家咖啡店卖四种咖啡，然而每一种咖啡都可以添加N种添加剂中的任何一种。设计一个主类然后继承，会导致子类数量爆炸的问题（自己排列组合一下就知）；给Coffee类一些属性，让它们自己记录有没有某一种添加剂并计算价格，刚会使代码需要不停地修改，每增加一种添加剂都要改变类。

根据前两个模式的观点，分离变化，多用组合少用继承XXX，加上经验，就有了装饰者模式，它的图是这样的（箭头代表继承）：

  （点击查看原图）

这是咖啡的具体实现方法：

其实Java　I/O里面之所以类那么多又封装得很好，也是由于使用了这种模式：

然后为什么要这样为什么不要那样，这类的问题，都在原书的79-107页。

这是本章节得到的模式（在105页）：

完毕