Z.W.F.'s Blog

博客转移到新域名www.zhangweifang.com

Z.W.F. — Sun, 28 Mar 2010 10:04:41 +0800

博客转移到新域名www.zhangweifang.com啦。朋友们去看看吧。哈哈。

这个域名将于5月1日更换新内容啦。准备专门放“段子”，嘿嘿。

【转】 SQL Server日志清空方法

Z.W.F. — Tue, 22 Dec 2009 15:52:49 +0800

原文出处：http://blog.csdn.net/cnming/archive/2009/03/11/3979290.aspx

原文作者：cnming 来自：cnming的专栏

在查询分析器中顺序执行以下三步，其中 databasename 为你的数据库文件名

1.清空日志：DUMP TRANSACTION databasename WITH NO_LOG

2.截断事务日志：BACKUP LOG databasename WITH NO_LOG

3.收缩数据库：DBCC SHRINKDATABASE(databasename)

–///////////////////

SQL Server日志清空方法

一种方法：清空日志。
1．打开查询分析器，输入命令 DUMP TRANSACTION 数据库名 WITH NO_LOG
2.再打开企业管理器–右键你要压缩的数据库–所有任务–收缩数据库–收缩文件–选择日志文件–在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了。

方法二：

清空日志：

——————————————
BACKUP LOG 库名 WITH NO_LOG

DBCC SHRINKFILE(‘日志文件名’,新的大小数值型如1)

日志文件名是这样的:

select name from sysfiles
如:
mastlog

———————————————
backup log DATABASENAME
with truncate_only
dbcc shrinkdatabase (DATABASENAME,SIZE)
若每天有whole back up的话可以设置一job，
每隔三天或一个星期清空一次
这样的话日志就不会长大了哦
————————————-
1：删除LOG
1：分离数据库
2：删除LOG文件
3：附加数据库
此法生成新的LOG，大小只有500多K 再将此数据库设置自动收缩

2:清空日志
DUMP TRANSACTION 库名 WITH NO_LOG

再：
企业管理器–右键你要压缩的数据库–所有任务–收缩数据库–收缩文件–选择日志文件–在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个数,确定就可以了

方法三：
第一步：
backup log database_name with no_log
或者backup log database_name with truncate_only –no_log和truncate_only是在这里是同义的，随便执行哪一句都可以
第二步：
1. 收缩特定数据库的所有数据和日志文件，执行dbcc shrinkdatabase (database_name,[,target_percent])–database_name是要收缩的数据库名称；target_percent是数据库收缩后的数据库文件中所要的剩余可用空间百分比
2.收缩一次一个特定数据库中的数据或日志文件，执行dbcc shrinkfile(file_id,[,target_size]) –file_id是要收缩的文件的标识 (ID) 号,若要获得文件 ID，请使用 FILE_ID 函数或在当前数据库中搜索 sysfiles；target_size是用兆字节表示的所要的文件大小（用整数表示）。如果没有指定，dbcc shrinkfile 将文件大小减少到默认文件大小

两个dbcc都可以带上参数notruncate或truncateonly，具体意思看帮助。

方法四：
（这个方法在sqlserver2000的环境下做一般能成功，在sqlserver7及以下版本就不一定了）：
第一步：
先备份整个数据库以备不测
第二步：
备份结束后，在Query Analyzer中执行如下的语句：
exec sp_detach_db yourDBName,true –卸除这个DB在MSSQL中的注册信息
第三步：
到日志的物理文件所在的目录中去删除该日志文件或者将该日志文件移出该目录
第四步：
在Query Analyzer中执行如下的语句：
exec sp_attach_single_file_db yourDBName, ‘d:\mssql7\data\yourDBName_data.mdf ‘
–以单文件的方式注册该DB，如果成功则MSSQL将自动为这个DB生成一个500K的日志文件。

以上方法在清除log日志中均有效。
但，能否让sql server不产生log日志呢？以上方法好像均无效。
我这儿正好有个case：
我客户的sql server每天都会产生4，500M的log日志，每天都清除一下，非常不便。有没有办法实现不产生log日志呢？

我分析了一下客户产生log日志的原因，并且做了相应测试。
客户是每天将数据库清空，从总系统中将数据导入到sql server里。我感决sqlserver在插入时产生log不大，在delete整个库时产生log极大。
比如：
SELECT * into test_2 from b_bgxx
共45000条记录，产生十几M log，如果
delete from test_2
产生80多M log，这明显存在问题。

虽然可以换成
truncate table test_2
但我还是希望能找到不产生log的方法。就如oracle不产生归档一样。

【转】最近降生的新物种-光腚鬃驹

Z.W.F. — Mon, 14 Dec 2009 22:42:49 +0800

光腚鬃驹

马勒戈壁上又一种奇蹄类动物，在漫长的进化过程中由于臀部的毛被河蟹剪光，故得名。与草_泥_马仅存在物种上的血缘关系，并称马勒戈壁两大神兽“草_泥_马光腚鬃驹”

光腚鬃驹在马勒隔壁的食物链中处于相对高端的位置，受制于河蟹。多寄生。因不需要啃食卧草，咀嚼能力退化，没有牙齿。运动神经发达，但脑神经系统进化不完全，有残缺，但不影响繁殖。

与很多动物用气味，排泄物来标记领地不同，光腚鬃驹是通过控制领地内龟群的活动，以大量的龟腚来标记领地的。但龟腚的出现同时会引来大量的草_泥_马，因此在马勒戈壁上光腚鬃驹对自己领地的控制并不十分的有效。

2/3的项目总结

Z.W.F. — Wed, 11 Nov 2009 19:48:56 +0800

项目概况：网上商城项目，类似知名的凡客诚品。但网上商城经营种类繁多。.net开发，数据库为SQLserver2000。开发时间大概60工作日，大陆货的项目。但是搞的很累很费劲。

总结：

1.项目对目前的团队基本是全新的项目，在没有任何人参与过完成商城开发的基础上，项目经理（或者架构师）应该对整个项目有至关重要的作用，业务流程必须明确、清晰，所用技术（框架）也应该是团队相对熟悉的。

2.客户的需求分析不明确的时候，尽量确定小型、频繁的迭代（Scrum是非常合适的），短周期的迭代、确定的小目标、可演示的Sprint成果可以帮助客户明确需求，更减少了到项目交期客户反复变更/增加需求造成的反反复复，磨磨蹭蹭。

3.产品经理或者营销人员，要针对项目预算，成本，跟客户良好的周旋，防止6万的项目做成10万的工作量，同样让客户满意，并知悉软件劳动同样“花多少钱买多少功能”。

4.文档是非常重要的东西，但要看情况，文档有时候反而会成为项目的羁绊，项目组成员会让文档“烦死”，就像小学时候恨写作文。单独的文档工程师可能没有必要，但项目中后期，项目经理或者开发的Team Leader需要注意整理文档，对内是项目各模块间的接口文档和测试用例，对外最重要的是“帮助文档”，客户可能不知道我们开发时候有意或无意的对需求进行的“灵活”处理。

5.如果你是客户，不要吹“牛逼”，虚心是重要的，当讲则讲，就算你是客户，也用不着当上帝摆谱，否则只会显示你的无知和空虚，三两鸭子二两嘴。（该条总结属于我唠叨，过过隐。）

6.软件是长出来的，不是开头就一份需求分析确定的，作为软件开发方，需要以服务的姿态对待客户的变更，在成本允许的情况下，尽量满足客户。谁都不是圣贤，最初的需求分析也就是项目过程中的一个Alpha版本而已。

先总结这些吧，毕竟项目没完全完成，2/3的总结更像突然的“头脑风暴”，仅仅作为临时笔记而已。

抓紧学习，努力前进。

ps:去他妈的光棍节。人都没事装什么寂寞，天天有妞泡的人到了光棍节才他妈的兴奋。

【转】敏捷，把纪律留下。

Z.W.F. — Wed, 28 Oct 2009 22:37:08 +0800

在很多人看来，实施了敏捷，似乎就等于纵容程序员，允许他们不把纪律放在眼里。事实是这样子么？

文／金明

在软件行业，大部分经理们都希望自己率领的团队能像军队一样具有铁的纪律性。在一次敏捷培训中，我们与众多来自国内软件公司的项目经理们讨论了敏捷，以及他们现在各自的开发方法和问题。闲谈中，一位学员冒出一句，“开发团队应该像军队，不仅要整体阵法严密，而且每个兵都要纪律分明。”这次培训主要是介绍敏捷的技术实践，比如测试驱动开发、持续集成、用户故事等，该学员认为这些敏捷实践不仅可以提高员工的技战术，还可以塑造团队成员的纪律性。如果这些敏捷实践在日常开发中都能落在实处，势必将提高团队成员的“战斗素养”和“战术素养”。一言以蔽之，相较于其他软件开发模式，敏捷方法对团队成员的纪律性提出了更高的要求，鼓励团队成员成长为项目经理心中的“合格军人”。

其实，抛开敏捷方法，哪一种软件开发方法又何尝不强调团队成员的纪律性？计划驱动的传统型开发方法给软件过程制定了严格的计划书和检验标准，希望能提高团队的纪律性。它们的出发点是对的，但因为缺少了具体的技术实践导致计划书并不能匹配团队的真实状态；检验标准大多是着眼于与最终交付软件无关的中间文档，这些都使得成员在工作中对项目开发的约束力感受不深。比如，很多项目里面的规范说明书、WBS表和甘特图都画得非常详细，但大多数时候这些东西与项目真实情况的落差太大，很难指导督促成员的日常开发工作。而且，这些文档与需要交付的软件产品的关联性不强，也很难能让成员和其他人通过这些文档建立对软件交付的信心。长期看到团队的表现与计划的不相符，项目经理们往往会感叹团队的纪律性不行。那么，为什么说敏捷方法能相对一定有效地提升团队成员的纪律性呢？我们先来看看纪律的定义。

纪律

一般来说，纪律有三种基本涵义：1. 纪律是指惩罚；2. 纪律是指通过施加外部约束达到纠正行为目的的手段；3. 纪律是指对自身行为起作用的内在约束力。这三层意思概括了纪律的基本内涵，同时也反映出良好纪律的形成过程是一个由外在的强迫纪律逐步过渡到内在自律的过程。从纪律的含义来看，达到自律是最终的目标，也是施加外部约束的目的所在。通过奖惩来达到一定的纪律性，比如程序员开发过程中的bug 率等等，这是生活中最常见的一种形式。这种方法因为检查的结果与具体生产过程差得太远，而且评判标准还是比较粗放，所以应该是最低级的方式。施加外部约束，比如检查列表，指导产品的具体生产，可以评判成员的各个环节是否符合标准，应该算中级方式。只有自律，真正让成员把纪律的观念贯穿在生产的每个环节，主动改进，从而改善生产。而这，也是纪律性的高级方式。

对比这个标准，我们可以看到：计划驱动型的软件方法学强调更多的是奖惩，也涉及到一些外部约束（代码复审等），这也是为什么它们在培养团队成员纪律性上难度比较大。而敏捷方法，通过强调承诺，强调每个成员都是“理性人”的事实，借助于成员的自律性来达到严明的纪律性。国内知名技术网站InfoQ，除了有限的几位全职员工，大部分中文编辑都是社区活跃分子，他们走到一起，通过之间的承诺和信任维持着日常工作。撇开具体项目团队而言，这就是敏捷团队最好的写照。但是，我们也应该看到，InfoQ类型的团队是可遇不可求的。现实中，大部分的开发团队还是良莠不齐，项目经理们很难去完全授权给手下的员工。为什么敏捷方法又能有效地提升成员纪律性呢？答案在于敏捷方法不仅仅强调承诺，也包含了丰富的技术实践：不仅给个人带来更短更频繁的反馈，也给团队和组织带来了多层次较全面的反馈。而反馈的频繁程度，则是外部约束发挥作用的重要基础，也即提升纪律性的重要手段。

戴明环（PDCA）

我们来看看被认为是组织或团队改进或解决质量问题的基本准则——戴明环。戴明环（PDCA）由美国质量管理博士戴明在20 世纪50 年代提出，PDCA是英语单词Plan（计划）、Do（执行）、Check（检查）和Action（行动）的第一个字母，该循环按照“计划－执行－检查－行动”的顺序进行，并且循环不止地进行下去，是一个立体多层级的螺旋式演化过程。PDCA循环最开始是用在质量管理领域，但实际上它是有效进行任何一项工作的合乎逻辑的工作程序，是放之四海而皆准的指导性原则。下面我们就用它来说明外部约束对纪律养成是如何影响。

PDCA 循环里面的Action 是一个循环的关键，对Check 结果进行处理，成功经验加以肯定并适当推广、标准化；失败的教训加以总结，未解决的问题放到下一个PDCA循环里，但它必须以上一环节的Check 结果为基础。如果Check 不到位，不能具体到实际工作，Action的正确性和出发依据就很值得商榷。软件开发是一个以不确定性为主要特征，强调知识的活动。为了采取的Action具有较高的正确几率，更需要强调开发过程的Check 比较频繁、具体，不断给团队提出直接的反馈，这样才能减少不断累积的不确定性最后带来成不可控制的后果。如此来看，短而频繁的反馈对外来约束真正施加到个人的效果是非常重要的。

PDCA循环还有一个特点是多层级性：各层级质量管理都有一个PDCA循环，形成一个大环套小环，一环扣一环，互相制约，互为补充的有机整体。软件开发通常会把个人、团队和组织都牵扯进来：个人完成功能的开发，团队完成软件的开发，组织负责完成客户需求的完成。传统的软件开发方法更多的是强调团队、组织层级的计划、图表等文档，关注于团队与组织层级的反馈。对于真正创造产品质量的日常开发环节，则缺少必要的检查和反馈。与之相反，支撑敏捷方法的敏捷实践，就从“个人－团队－组织”的几个层面都提供了相应的反馈：低层次的反馈，为上一层次的反馈提供了依据，同时也作为上一层次反馈的落实和具体。

敏捷实践

我们从“个人－团队－组织”等的不同层次选取几个突出实践简要解释它们是如何提供频繁、直接的反馈。

个人层级

测试驱动开发能给开发人员提供最直接也是最快捷的反馈：先写测试，再用最简单的方式实现，再重构代码以符合简单设计的原则。如此短间隔的反馈能很快地告诉开发人员刚才增加的代码是否破坏了已有的功能。而且，已完成test case 的列表能很清晰地告诉其他人开发任务的完成情况。对比着用户故事的验收条件，开发人员很容易评估剩余的工作量，并不至于破坏已有的功能。

团队层级

敏捷实践中的持续集成，强调尽可能快尽可能频繁地提交代码，与系统的其他部分进行集成。在提交新代码之前，必须保证本地的构建过程是成功无误的。谁提交代码使得持续集成服务器构建失败，必须立即停下手中的活，负责修复构建直到成功。下班之前必须要保证持续集成服务器上的集成构建状态是成功的。这样，开发人员和团队很容易检查新功能与其他模块的集成，另外也把未来的集成风险降到最低。

组织层级

用户故事是开发团队与客户之间讨论需求的基础。用户故事必须对客户有真实可见的业务价值，并且必须包含对该需求完成的验收条件。用户故事作为业务分析人员、测试人员、项目经理与客户一起确定的用户需求，具有经过验证的确切性。开发人员开发故事之前，必须和业务分析人员、测试人员沟通理解需求；开发完故事之后，必须要由业务分析人员与测试人员根据验收条件进行验收。组织和客户之间可以针对达成共识的故事列表来分析项目状态，从而验证或者修改项目计划。

总之，敏捷众多实践就像一张全面立体的安全网，时时刻刻从各个角度给项目成员、团队，以及组织提供短周期的反馈，帮助团队成员不仅感受到开发过程中的同伴约束，而且也可以感受到来自整个团队的约束，甚至是来自组织之间的约束。这些外来约束也像是缠绕在个人周围的催化剂，纠正或改善个人的行为，达到提升个人的纪律性。

作者简介：

金明，ThoughtWorks咨询师，InfoQ中文社区编辑，SCJP，系统分析师。他在机械模具、数字安全证书，以及海洋航运等行业拥有超过4年的企业应用开发经验。他对敏捷方法学，特别是敏捷咨询和项目管理，以及面向对象分析和架构设计等方面有浓厚的兴趣。

在很多人看来，实施了敏捷，似乎就等于纵容程序员，允许他们不把纪律放在眼里。事实是这样子么？

文／金明

纪律

戴明环（PDCA）

敏捷实践

我们从“个人－团队－组织”等的不同层次选取几个突出实践简要解释它们是如何提供频繁、直接的反馈。

个人层级

团队层级

组织层级

作者简介：

还要入门C#

Z.W.F. — Wed, 28 Oct 2009 21:54:57 +0800

很早就开始看《C#图解教程》，但是总是看过就往，可能就是因为没有项目做的原因吧。突然记起小学时候学习Logo到入迷的状态，再看看现在的学习韧性，简直越长越完蛋。

对自己的定位一直不清晰，不知道干什么好。但是经历了卖电脑、摄像记者、视频后期、电厂、ERP实施、IT、销售等工作，发现自己现在定位越来越不清晰。不应该这样的。不能辜负滕老师的希望，记得在大二数据库课程结束后，老滕说“你将来不干开发可惜了。”那时候小学做Logo开发的感觉立马又刺激了一下我的神经。好久没有体会到写代码那种畅快淋漓了。

一直对很多项目的开发心存意见，为什么就不能做的方便点。其实开发人员有苦衷的，什么苦衷？只有干了开发才知道，为了体验开发的苦衷，更为了体验能将自己的想法付诸实践的畅快感觉。我真的必须要沉下心来学习锻炼了。

毅力，韧性，坚持，不耻下问。我所缺乏的，但却是学习过程中需要的。

加油。

Google Reader快捷键中文版

Z.W.F. — Thu, 22 Oct 2009 22:42:55 +0800

Google Reader快捷键中文版（译者：shixinyu）

from http://www.gseeker.com/50226711/eeaeiegoogle_readereaec_45147.php

●j/k–上一个条目/下一个条目
●空格键/上档键＋空格键–向下翻一页/向上翻一页＝PageDown/PageUp
●n/p–向下/向上选择（仅List查看模式）
●o–展开条目（仅List查看模式）
●回车键–展开条目（仅List查看模式）
●s–标记所选择的条目星号（取消标记）
●上档键＋s–共享所选择的条目

●m–标记为已读或未读
●t–给一个条目设置Tag
●v–查看原文（即打开条目相应的链接）
●上档键＋a–标记所有条目为已读
●1–展开预览方式
●2–列表预览方式
●r–刷新
●上档键＋n/上档键＋p–向下/向上选择（左侧导航）
●上档键＋x–展开/收起导航
●上档键＋o–打开导航中的订阅
●gh–打开Google Reader首页
●ga–显示所有条目
●gs–显示已标记星号的条目
●gt–打开标签选择（这个很炫！）
●gu–打开已订阅的RSS（一样很炫！）

MindManager 8 is an excellent software for Mind Map

Z.W.F. — Thu, 15 Oct 2009 22:09:27 +0800

I updated my MindManager 7 to 8.1.920, there is no big chang on the views, it also looks like MS Office 2007.

There are some new functions that make me exciting.

1.Share and Share alike. A whole mind map can be export as a mindjet player. The file exported is swf or pdf. Both of them are Dynamic, your can expand/collapse branches. That’s very useful.

2.Integrated many functions. We can edit office files in MindManager8 and browse website in the embedded browser.

3.Task Automation. Many some task images will roll-up automatically. That souds good, but I didn’t use that untill now.

FreeMind is another mind mapping software I used, this is an open source software, and it’s free of charge. But the functions of FreeMind are not good as them of Mind Manager 8. If you want to use Mindjet MindManager 8, US$349 per user will be paid.

生活定律

Z.W.F. — Tue, 13 Oct 2009 22:55:51 +0800

1、蝴蝶效应：上个世纪70年代，美国一个名叫洛伦兹的气象学家在解释空气系统理论时说，亚马逊雨林一只蝴蝶翅膀偶尔振动，也许两周后就会引起美国得克萨斯州的一场龙卷风。蝴蝶效应是说，初始条件十分微小的变化经过不断放大，对其未来状态会造成极其巨大的差别。有些小事可以糊涂，有些小事如经系统放大，则对一个组织、一个国家来说是很重要的，就不能糊涂。

2、青蛙现象：把一只青蛙直接放进热水锅里，由于它对不良环境的反应十分敏感，就会迅速跳出锅外。如果把一个青蛙放进冷水锅里，慢慢地加温，青蛙并不会立即跳出锅外，水温逐渐提高的最终结局是青蛙被煮死了，因为等水温高到青蛙无法忍受时，它已经来不及、或者说是没有能力跳出锅外了。青蛙现象告诉我们，一些突变事件，往往容易引起人们的警觉，而易致人于死地的却是在自我感觉良好的情况下，对实际情况的逐渐恶化，没有清醒的察觉。

3、鳄鱼法则：其原意是假定一只鳄鱼咬住你的脚，如果你用手去试图挣脱你的脚，鳄鱼便会同时咬住你的脚与手。你愈挣扎，就被咬住得越多。所以，万一鳄鱼咬住你的脚，你唯一的办法就是牺牲一只脚。譬如在股市中，鳄鱼法则就是：当你发现自己的交易背离了市场的方向，必须立即止损，不得有任何延误，不得存有任何侥幸。

4、鲇鱼效应：以前，沙丁鱼在运输过程中成活率很低。后有人发现，若在沙丁鱼中放一条鲇鱼，情况却有所改观，成活率会大大提高。这是何故呢? 原来鲇鱼在到了一个陌生的环境后，就会“性情急躁”，四处乱游，这对于大量好静的沙丁鱼来说，无疑起到了搅拌作用;而沙丁鱼发现多了这样一个“异已分子”，自然也很紧张，加速游动。这样沙丁鱼缺氧的问题就迎刃而解了，沙丁鱼也就不会死了。

5、羊群效应：头羊往哪里走，后面的羊就跟着往哪里走。羊群效应最早是股票投资中的一个术语，主要是指投资者在交易过程中存在学习与模仿现象，“有样学样”，盲目效仿别人，从而导致他们在某段时期内买卖相同的股票。

6、刺猬法则：两只困倦的刺猬，由于寒冷而拥在一起。可因为各自身上都长着刺，于是它们离开了一段距离，但又冷得受不了，于是凑到一起。几经折腾，两只刺猬终于找到一个合适的距离：既能互相获得对方的温暖而又不至于被扎。刺猬法则主要是指人际交往中的“心理距离效应”。

7、手表定律：手表定律是指一个人有一只表时，可以知道现在是几点钟，而当他同时拥有两只时却无法确定。两只表并不能告诉一个人更准确的时间，反而会使看表的人失去对准确时间的信心。手表定律在企业管理方面给我们一种非常直观的启发，就是对同一个人或同一个组织不能同时采用两种不同的方法，不能同时设置两个不同的目标，甚至每一个人不能由两个人来同时指挥，否则将使这个企业或者个人无所适从。

8、破窗理论：一个房子如果窗户破了，没有人去修补，隔不久，其它的窗户也会莫名其妙地被人打破;一面墙，如果出现一些涂鸦没有被清洗掉，很快的，墙上就布满了乱七八糟、不堪入目的东西;一个很干净的地方，人们不好意思丢垃圾，但是一旦地上有垃圾出现之后，人就会毫不犹疑地抛，丝毫不觉羞愧。

9、二八定律(巴莱多定律)：19世纪末20世纪初意大利的经济学家巴莱多认为，在任何一组东西中，最重要的只占其中一小部分，约20%，其余80%尽管是多数，却是次要的。社会约80%的财富集中在20%的人手里，而80%的人只拥有20%的社会财富。这种统计的不平衡性在社会、经济及生活中无处不在，这就是二八法则。二八法则告诉我们，不要平均地分析、处理和看待问题，企业经营和管理中要抓住关键的少数;要找出那些能给企业带来80%利润、总量却仅占20%的关键客户，加强服务，达到事半功倍的效果;企业领导人要对工作认真分类分析，要把主要精力花在解决主要问题、抓主要项目上。

10、木桶理论：组成木桶的木板如果长短不齐，那么木桶的盛水量不是取决于最长的那一块木板，而是取决于最短的那一块木板。

11、马太效应：《圣经-马太福音》中有一句名言：“凡有的，还要加给他，叫他有余;没有的，连他所有的，也要夺过来。”社会学家从中引申出了“马太效应”这一概念，用以描述社会生活领域中普遍存在的两极分化现象。

英语之殇

Z.W.F. — Fri, 09 Oct 2009 23:10:57 +0800

自上小学就学英语，到了现在都一直感觉英语与考试密不可分。学英语也有n多流派，考试包过型、华尔街等类似的实用型等等，但是我们还是不知道英语怎么说。自己感觉可能是我们把会说英语和不会说英语进行了一个过分严格的界定吧。其实英语只是一种交流工具而已，既然是工具就要“用”，越用越熟练。

现在呆的公司虽然不经常接触外国客户，但是一来就是非英语的欧洲国家，上次的法国客户把我整的就够惨了，这次又是一个意大利朋友，还好都有翻译，自己随便叨叨几句就行，不过听起来可就完了。纯正的英语都说不好，更何况“意大利面”味道的英语。

真是挺羡慕随行的Chen mm，英语、意大利语那是张口就来，不知道会不会冷不防来个法语、俄语抑或是阿拉伯语，天啊。

我的英语啥时候能张口就来呢？词汇量怎么涨上去呢？不过我感觉还是找个只懂英语的上司比较好，逼着自己提高，哈哈哈。