一个看图识别性格的测验

[webnote]

 

 

转载一个看图识别性格的测验

收藏到您的美味书签

Published on 09/23,2006

　　这个性格测验来自 车东的博客，主要因为头一次看到他写技术以外的东西，而且又是比较新鲜的有互动性的内容，所以就全文转载了。

这些图片是 (Ulla Zang) 跟一位心理学家一起合作的成果，并且经过历时几年的全球性测试。收到这个研究的响应之后，再小心地调较各个图片的颜色及形状，然后再次进行测试，直至得到这些非常成功的图片，这些图片代表了九种不同的性格。 希望你喜欢这个测验！

　　请看以下的图片，并选出你最喜爱的一张 (同时考虑形状和颜色)。

 

 

　　我比较喜欢 4 和 6，结果发现 6 的描述跟我的性格更接近。如果有兴趣的话，您也可以回帖说明测试结果是否准确。

　　测试结果说明：
　　1) 时常自我反省,敏感的思想家

• 你对于自己及四周的环境能够比一般人控制得更好更彻底。
• 你讨厌表面化及肤浅的东西；
• 你宁愿独自一人也不愿跟别人闲谈，但你跟朋友的关系却非常深入，这令你的心境保持和谐安逸。
• 你不介意长时间独自一人，而且绝少会觉得沉闷。

　　2) 独立，前卫，不受拘束

• 你追求自由及不受拘束，自我的生活。
• 你的工作及消闲活动都与艺术有关。
• 你对于自由的渴求有时候会使你做出令人出人意表的事。
• 你的生活方式极具个人色彩；你永远不会盲目追逐潮流。
• 相反地，你会根据自己的意思和信念去生活，就算是逆流而上也在所不惜。

　　3) 精力充沛，好动，外向

• 你不介意冒险，特别喜欢有趣的，多元化的工作。
• 相比之下，例行公事及惯例会令你没精打采。
• 你最兴奋的是可以积极参与任何比赛活动，因为这样你就可以在众人面前大显身手了。

　　4) 务实，头脑清醒，和谐

• 你作风自然，喜欢简单的东西。
• 人们欣赏你脚踏实地，他们觉得你稳重，值得信赖。
• 你能够给予身边的人安全感，你给人一种亲切，温暖的感觉。
• 你对于俗气的，花花绿绿的东西都不屑一顾，对时装潮流抱着怀疑的态度；
• 对于你来说，衣服必须是实用及大方得体的。

　　5) 专业，实事求事，自信

• 你掌管自己的生活，你相信自己的能力多于相信命运的安排。
• 你以实际，简单的方式去解决问题。
• 你对日常生活中所遇到的事物抱有现实的睇法，并且能够应付自如。
• 人们知道你可担重任，因此都放心把大量工作交给你处理。
• 你那坚强的意志使你时刻都充满信心。
• 未达到自己的目标之前，你绝不罢休。

　　6) 温和，谨慎，无攻击性

• 你生性随和，但处事谨慎。
• 你很容易认识朋友，但同时享受你的私人时间及独立生活。
• 有时候，你会从人群中抽身而出，一个人静静地思考生活的意义，并自娱一番。
• 你需要个人的空间，因此有时会隐匿于美梦当中，但你并不是一个爱孤独的人。
• 你跟自己及这个世界都能够和陆共处，而你对现状亦非常满意。

　　7) 无忧无虑，顽皮，愉快的人

• 你喜欢自由自在，无拘无束的生活。
• 你的座右铭是：生命只能活一次，因此你尽量享受每一刻。
• 你好奇心旺盛，对新事物抱有开放的态度；你向往改变，讨厌束缚。
• 你觉得身边的环境都不断在变，而且经常为你带来惊喜。

　　8) 浪漫，爱幻想，情绪化

• 你是一个感性的人。你拒绝只从一个严肃，理智的角度去理解事物。
• 你的感觉亦十分重要。事实上，你觉得人生必需要有梦想才叫活得充实。
• 你不接受那些轻视浪漫主义及被理智牵着鼻子走的人；
• 而且不会让任何事物影响到你那丰富的感情及情绪。

　　9) 具分析力，可靠，自信

• 你对事物的灵敏度令你可以发现到旁人忽略了的东西。
• 这些就是你的宝石，你喜欢发掘这些美好的东西。
• 你的教养对于你的生活有很特别的影响。你有自己高雅独特的一套，无视任何时装潮流。
• 你的理想生活是优雅而愉快的，而你亦希望跟你接触的人们都是高雅而有教养的。

中国共享软件走向国际指南

[webnote]

[software] 

 

2005-8-11 10:41:50

中国共享软件走向国际指南

　　你的软件也能挣钱 共享软件走向国际指南

　　版权声明：可以任意转载，转载时请务必以超链接形式标明文章原始出处和作者信息及本声明。

 共享软件为何要走向国际

 　　共享软件为何要走向国际？

　　理由很简单，不少人做共享软件走国际路线，月入数万美元，而同样软件走国内路线恐怕很难达到这个数．（原因大家都知道）

 　　软件开发三个永恒的主题是：

　　一.软件的功能及创意

　　二.软件的推广

　　三.软件的保护　　

　 当我对Visual Studio .NET程序设计初步入门时，我开始考虑程序的推广。可以说，共享软件的成功关键在于推广。

　 纯粹从市场角度出发，软件推广考虑的顺序必然是国际→国内。无论如何，国际市场要比国内市场优越得多。再加上国内软件市场不成熟，许多共享软件根本不考虑国内市场。

　　所以，有人下结论：

　　1）能做软件的，赶紧做国外的市场

　　2）不能做软件，但还会编程的，赶紧想办法找个美国公司工作（一年最差6，7万美元的年薪吧，水平高一点的10万以上没问题）

　　但是有个问题，我的English并不精通，共享软件重在服务，我的poor English如何和国外用户交流？基于这个想法，我一度想先面对国内市场，等English好一点后再开拓国际市场。这个想法无疑是幼稚的。正因为是 poor English,起点更加要高，无论成功与否，至少可以乘机逼自己恶补English。更关键是要抓住时间，抓住机会，先行一步。

　　正如arbiter在《共享软件之勇士义旅》一文所说："国家四级水平+金山词霸足以应付这些困难，关键的是看你是不是想去做而已"。

把共享软件提交到哪些站点

　　1.首先是提交搜索引擎

　　关于搜索引擎的有价值的网站：

　　http://www.marketposition.com

　　http://www.webposition.com

　　2.提交到软件下载网站

　　可参考下面网站查找下载网站地址

　　http://www.softwaremarketingresource.com/

　　http://www.trialware.org/sites.html

　　http://www.asp-shareware.org/users/searchsites.asp

　　十个访问量最大的国外下载网站

　　http://www.alexa.com/browse/general?mode=general&catid=823454 　　

　　不少人认为做海外共享软件一定要提交到http://www.download.com, 但提交到download至少要79$，一般国人没有支付途径，怎么办？

　　首先你要有一张国际信用卡，去中国银行办理吧，只要你抵押$500就可以办到了，招行也行，不需要抵押，但是审核比较麻烦。Visa和Master都可以。

　　Download.com的提交软件在upload.com，注册一个账号（免费的），然后把你的软件英文名称与介绍都准备好，注意英文不要有任何拼写错误呀，这个提交的资料以后是不可以更改的！我提交的时候就没有注意，结果有好几个拼写错误，唉~ Download.com提交最低费用需要$79，网站上说5个工作日的处理时间，实际上2天左右就可以审批通过了！download.com上同一类别的软件默认是按照审批通过的日期排序的，因此朋友们在提交以前看一下你要提交的类别每个月在哪几天很少有人提交，那么你就在这几天提交，这样你就可以使你的软件保持在第一页多几天的！

　　我可没有国际信用卡，是不是就没有办法了呢，办法是有的，我是花了650大洋请我的主机服务商帮我打钱的。我的经验是提交以前果先做市场调查的工作，并市场和你的软件都有较充分的了解，英语也要还可以，不然走向海外不一定会成功的。我是2004年8月1日购买海外主机的，现在是2004年12月27日，其实我现在已经暂时不做海外了，主要是因为我的英语水平还是不太行，做一下准备工作再战海外。

做海外市场，用国内还是国外主机

　　这其实不是问题，做海外市场，当然是用海外主机，最好是用美国主机．我用的是国内服务商的美国主机，后来发现我的选择是对的，不是说国内服务商的主机质量最好，是因为我的英语不很精通，控制面板全是英文，我不懂的地方方便在QQ里问（当然用中文问了）

　　 用过海外主机，才知道什么样的主机是垃圾．我说得偏激点，我使用过国内的主机都是垃圾．海外主机控制面板里有几十项自定义功能，安装一个论坛，几下点击就搞定．还有流量统计，日志分析等等，还有许多我还没有用过，还不会和，有空要好好试试．

　　为避免打广告之嫌，我就不说我用的是哪家服务商的美国主机了．

　　如果你自己有信用卡,我强烈要求你自己到下面地址找自己想要的主机,请不要问我为什么!

　　http://www.webhostingmall.com/

　　http://www.hostsearch.com/

　　http://www.10-cheapwebhosting.com/ 

　　如何查询某台主机上建了多少站点？

　　用这个可以得到很详尽的服务器信息.

　　http://whois.sc  

　　Web hosting talk

　　要看真正的评论，在这里： http://www.webhostingtalk.com/search.php  

　　比较常用的口碑不算太差的虚拟主机

　　http://www.pair.com

　　http://www.powweb.com

　　http://www.lunarpages.com  

　　你的虚拟主机稳定吗？

　　http://www.linkwan.com/gb/broadmeter/htmltest/netmechanic.htm

　　不过得看清楚是不是美国的主机哦.买错了不要找我. 

　　域名的问题

　　一般国外的.COM域名要$12-$15,稍微贵了点,而且还得留意迁出你的域名时的费用,价格相差很大! 如果你的英文不是很好, 图个方便,在国内买个支持自定义DNS的域名还是合算点的.  

共享软件国外收款指南

  　　1.很多朋友准备接受国外的共享软件注册中心的服务的时候

　　也许对怎么收取你的共享软件销售所得的美金有些茫然，现将我所知的告诉大家，希望对新加入这一行的朋友有点帮助，对于熟于此道的朋友希望指正不对的地方，也或加入讨论更好的方法

　　其实从国外收取美金是一件很简单的事情

　　通常你在往一个注册中心提交你的软件的时候，都要求你设置你的软件的销售价格，也可以设置打折价

而在你在一个注册中心注册的时候，他们通常要求你填入你的收款最小额度（小于这个额度会在注册中心保留，直到达到或者超过这个额度）。然后设置你的银行帐号。

　　如果你第一次设置不正确或者没有清楚的情况就乱写了，没有关系，以后你可以更改这些信息，你看看有没有accont info链接，如果没有你就给support或者master发送SOS就可以了。他们会细心的解答你的问题。

　　通常收取美金又3种模式

　　1. Check 支票　当金额比较少时这样比较合算些

　　2. International Money Order国际汇款，这个慢而比较麻烦我就不多说了

　　3. Wire Transfer / Direct Deposit 直接转帐，通常是只有美国国内才可以

　　4. International Wire Transfer 《《《－－－－就这个了，这是最好的办法，不过通常一次你要被　　收取3，40美金左右的费用（不过相对几百几千美金来说，我希望大家能从心理把这点投入忽略不计了）

　　好，我现在来说说真么填写这些信息。

　　国际电汇(International Wire Transfer)，需要如下信息。

　　switch code : 转帐代码

　　bank : 银行名称

　　account owner : 帐户名

　　account NO : 帐号

　　《－－－－－前面的信息最重要

　　city :城市

　　country :国家

　　province :省

　　现在国内大多数银行都是可以收取国际汇款的，但是不是每种卡每种帐号的都支持，你在银行开户的时候一定要问清楚，这个帐号是不是能够存取美金！！！！

　　拿中行的一本通为例

　　你先去中行申请一个一本通（可选择港币还是美金，当然是选择美金作为外币总类了），OK，到现在为止就万事具备了。

　　如，你在深圳的罗湖支行办理的这个帐号。

　　switch code : BKCHCNBJ45A（每个城市不同，我是问了银行的MM好几次啊）

　　bank : bank of china,shenzhen branch,luohu subranch

　　（中国银行，深圳分行，罗湖支行，分行：branch，支行：subranch，你要还不放心，就问银行的妹妹了）

　　account owner : kugle（银行帐号，通常都是你的姓名的拼音）

　　account NO : 4766966-0138-0311340-1（银行帐号，就在卡上和存折上都有的）

　　city :shenzhen

　　country :china

　　province :guangdong

　　就这些了，如果你的注册中心网页上不能够设置，就给管理account的那个人发

送一个邮件告诉它这些就可以了。

　　可以到 http://www.swift.com/biconline/index.cfm 查你所在城市switch code和英文地址，页面右边有个BIC　quick search, 什么都不用填，点search,在新出来的页面City heading填你所在城市的拼音，再点search,就会出来你想要的结果.不过我所在的小城的switch code 倒没有在上面查到。 

　　还可以到http://www.bank-of-china.com/en/common/third.jsp?category=ROOT>en>Information%20Center>BOC%20Network>Domestic%20Branches&pages=4　　这个页面自己找找。

　　我找出如下,是地市一级，没有县一级:

SHAOXING BRANCH

201 MIDDLE RENMIN ROAD,

SHAOXING 312000,

ZHEJIANG PROV., CHINA

SWIFT: BKCH CN BJ 92D TLX: 37429 BOCSX CN

TEL: (86) 0575-5111333

FAX: (86) 0575-5134405

POST CODE: 312000　

关于共享软件的网上资源

　　共享软件如何走向国际？是许多程序员头大的事。有了网络，一切都简单了。理论上，只要你善于利用，可以从网络上找到一切答案。 

　　1.http://www.google.com

　　你可以在google用"共享软件"相关关键词搜索，可以找到大量共享软件相关链接。你可不要告诉你不会用google。 

　　2.http://www.csdn.net

　　csdn的文档中心有许多共享软件相关文章，可作参考。你可在csdn的首页用"共享"作关键词搜索"文档标题。

　　csdn有个"共享软件（走向海外）"论坛，你先到csdn论坛http://expert.csdn.net/，再在左边目录"扩充话题"中可找到。 

　　3.http://www.cnsw.org　中国共享软件联盟

　　cnsw是讨论共享软件的专业论坛，里面许多内容很有指导意义。一些内容就整理自cnsw。

　　4.http://www.989888.com  聂永新搞的一个共享软件论坛，注册用户需要认证，里面有不少月入万刀的老鸟。　　

　　还有:  

　　中国共享软件论坛（989888）

　　 http://www.china-shareware.com/  

　　Association of Shareware Professionals 国外最大的共享软件组织，PAD标准的制订者

　　http://www.asp-shareware.org  

　　Trialware Professional Association

　　 http://www.trialware.org/  

　　Euro-Share - The Shareware industry's leading daily discussion list

　　 http://www.euro-share.net/  

　　GOOGLE论坛

　　http://groups-beta.google.com/group/alt.comp.shareware.authors  

　　Regnow的内部论坛

　　 http://forums.regnow.com/

　　共享软件有关经验共享：

　　Software Marketing Resource

　　http://www.softwaremarketingresource.com/  

　　DP Directory E-mail your press release to 1,000+ computer editors

　　http://dpdirectory.com/  

　　Shareware marketing articles

　　http://www.davetalks.com/  

　　Shareware blogs

　　http://sharewareblogs.com  

　　Small Business Software

　　http://www.small-business-software.net/  

　　Marketing Resource

　　http://www.marketingresource.com/  

　　Chanimal the ultimate resource for software marketing!

　　http://www.chanimal.com/  

　　Shareware Promotions

　　http://www.sharewarepromotions.com/  

　　Successful Shareware

　　http://www.semicolon.com/ShareSuccess/Shareware1.html  

　　关于搜索引擎的一些资源：

　　爱搜网

　　http://www.loveseo.com/  

　　Google 营销1 - 6

　　http://www.cnsw.org/bbs/viewthread.php?tid=2097  

　　相似页面检测器(Similar Page Checker)

　　http://www.webconfs.com/similar-page-checker.php

　　众所周知，Google会对拷贝页面内容进行排名惩罚。该工具可以检验两个页面的相似度，来判断是否会受到惩罚。如 　　http://www.sitepronews.com/freebooks.html 和 http://www.allbusinessnews.com/freebooks.html ，相似度达到80%，后者在Google中的PageRank排名值通过工具栏显示为0.  

　　Google排名监测工具（Free Monitor for Google)

　　http://www.cleverstat.com/google-monitor.htm

需要下载使用。该工具可以报告你的网站以某关键词在Google中的排名情况，以及同一关键词下排名前N位（自己设定位数）的网站URL。  

　　链接广泛度检测器(Link Popularity Check)

　　http://www.marketleap.com/publinkpop/

　　输入你的网站URL和随机显示的进入代码，你将获知在搜索引擎Alltheweb AltaVista Google/AOL HotBot/Inktomi MSN 中有哪些网站链接了你的网站，以及同一URL在Dmoz、Excite、iWon、Lycos、Overture等搜索引擎中的详细链接资料。你也可以同时输入5个竞争对手网站URL以进行对比，了解自己在竞争中所处地位。同样工具 http://www.trafficzap.com/linkpopularity.php ，可检测网站在Yahoo、Google、MSN、Lycos和Altavista的链接总数和具体链接的网站。  

　　搜索引擎抓取页面数量统计器(Search Engine Saturation)

　　http://www.marketleap.com/siteindex/

输入你的网站URL和随机显示的进入代码，你将获得搜索引擎Alltheweb、AltaVista Google/AOL、HotBot/Inktomi所抓取到的你的网站页面数量。你也可以同时输入3个竞争对手网站URL以进行对比，了解自己在竞争中所处地位。  

　　搜索引擎抓取内容模拟器(Search Engine Spider Simulator)

　　http://www.webconfs.com/search-engine-spider-simulator.php

输入你要查询的URL，获知Google可以抓取到的该页文本内容和链接。不妨对比测试一下使用大量文本和大量图片的页面所获得的内容悬殊的抓取结果。网络营销人也可以利用此工具来检测优化后的页面质量。支持中文字符。

 　　作者：Tuenhai　Email：king#tuenhai.com　QQ：83087　出处：www.Tuenhai.com

　　 下载带有 Google 工具栏的 Firefox      从 Google 下载相片软件

月光博客 [ http://www.williamlong.info/ ]

本文链接地址：http://www.williamlong.info/archives/225.html

• 相关文章(共享软件):
• 通过香港招行一卡通收回PayPal资金 
• 送给所有的共享新手 
• 到美国去，挣美元! 
• 软件创富 
• 影响中国软件开发的20人 
• 中国软件人,我为你哭泣 
• 关于正版和盗版软件的博弈 

• 文章排行

• 随机文章 　网站流量的数据统计和分.. 　重温大富翁游戏 　又一个网站地址被封了 　GOOGLE更新反向链接了 　流氓燕：如何与不同年龄.. 　预防夺命杀手－高血压 　提交表单后PHP不能获取提.. 　Google Hacking的实现以.. 　防止ASP下载的终极方法 　使用PING命令轻松判断TC..

  文章本月排行 　Google Earth中文版和卫.. 　Google Earth的十个常用.. 　外教开博客讨论如何玩弄.. 　声援孟广美 　使用日本代理服务器注册.. 　中国电信流氓软件遭媒体.. 　Google Earth开始支持中.. 　Google Adsense常用技巧.. 　寂静岭电影和寂静岭游戏.. 　微软服务和软件大全

  文章本年排行 　Google Earth揭密中国军.. 　Google Earth大量更新中.. 　Google卫星地图惊现中国.. 　Google Earth曝光美国航.. 　二月丫头，一脱成名 　Google卫星图片吓坏了印.. 　Google Maps卫星地图更新.. 　南洋理工校花和中国色狼.. 　Google Earth上的中国标.. 　Google地图下的美国机密..

• 该日志的Traceback地址:
• http://www.williamlong.info/cmd.asp?act=tb&id=225

Geek to Live: Take great notes

[webnote]

 

 

Geek to Live: Take great notes

by Gina Trapani

Like it or not, our work lives involve meetings - status meetings, planning conference calls, brainstorming sessions, meetings for the sake of meetings. But a meeting is only as valuable as the action taken after everyone's left the conference room.

Whether you're headed off to a business meeting, a university lecture, or a conference session, taking effective notes is a necessary skill to move your projects, your career and your education forward. Today I'll go over a couple of my favorite note-taking methods, as well as how to make your own custom notepaper to fit your needs.

The first two methods are especially useful for business meetings and professional conferences, where it's most important to separate different types of information.

Method 1: Symbolize the next action

Using notepaper or a simple text file on your laptop or tablet, indent the pages of your notes in from the left margin. Then, use a simple system of symbols to mark off 4 different information types in the column space left in the margin.

• [ ] A square checkbox denotes a to do item
• ( ) A circle indicates a task to be assigned to someone else
• * An asterisk is an important fact
• ? A question mark goes next to items to research or ask about

After the meeting, a quick vertical scan of the margin area makes it easy to add tasks to your to do list and calendar, send out requests to others, and further research questions. (This method is the brainchild of Michael Hyatt, someone who clearly has mastered the art of attending meetings.)

Method 2: Split your page into quadrants

Another way to visually separate information types is to split your note-taking page into quadrants and record different kinds of information - like questions, reference and todo's - into the separate areas on the page. Rumor has it this is how Bill Gates - someone known for taking amazingly detailed meeting notes - gets it done.

Method 3: Record and summarize - The Cornell Note-taking Method

A system more targeted towards students digesting large amounts of information on a daily basis, the Cornell note-taking method also separates the page into different areas, as pictured:

• Note taking area: Record lecture as fully and meaningfully as possible.
• Cue column: As you're taking notes, leave the cue column empty. Soon after the lecture, reduce your notes to concise jottings as clues for Reciting, Reviewing and Reflecting.
• Summaries: Sum up each page of your notes in a sentence or two.

• Note taking area: Record lecture as fully and meaningfully as possible.
• Cue column: As you're taking notes, leave the cue column empty. Soon after the lecture, reduce your notes to concise jottings as clues for Reciting, Reviewing and Reflecting.
• Summaries: Sum up each page of your notes in a sentence or two.

DIY notepaper

There are a few neat little webapps out there that produce custom PDF's of formatted, lined notepaper with various options for printing out before your meeting and possibly stowing in a binder.

Notepaper Generator [Simson.net]

Create a PDF of a lined page with a small monthly calendar in the header and an optional summary box in the upper right hand corner. Choose your font face and optionally include punch holes as well.

Cornell Method PDF Generator [Study Smarter]

Prints pages split up into the Cornell notepaper style with unlined, ruled or graphed sections. Optionally include your name, the date, and the name of your class, and up to 4 punch holes for use in a binder. Also, choose the line darkness on a scale from gray to black.

Notepad Generator [Michael Botsko]

This PDF notes template includes your name, number, the date, project name and splits the page into two sections: one for notes (with lines) and the other for action items with due dates, with optional punchholes.

What do you use to take notes in meetings? How do you keep your jottings organized and useful after the fact? Let us know in the comments or to tips at lifehacker.com.

Gina Trapani, the editor of Lifehacker, is getting better at taking worthwhile notes. Her semi-weekly feature, Geek to Live, appears every Wednesday and Friday on Lifehacker. Subscribe to the Geek to Live feed to get new installments in your newsreader.

爱美丽me

[webnote]

 

 

中文名称：爱美丽me
版本：更新至0625期
地区：大陆
语言：普通话
简介：


me0625

卷首语
广告大玩黑白照

iBlog爱博客
编辑博客大公开

iNews爱新货
秋冬金光闪闪BLING BLING秀

iFashion爱服装
换季怎么穿?
2006秋冬6大流行重点大分析

iStar爱明星
时尚名人STYLE教学~
大明星爱大包包

iStyle爱造型
美体穿衣手册
秋季不显臃肿穿衣法则

iBeauty爱美容
06秋冬彩妆广告模仿秀

iFitness爱健身
爱美丽一分钟瘦身操:
马步瘦腿操速学

iNews爱新货
秋天流行巧克力妆

iTaro爱塔罗
失温的爱情
塔罗星座双周报

iTest爱测验
秋天美食心理测验～我的可爱指数
高跟鞋心理测验～我的性感指数

iQA爱发问
BEAUTY 如何选去角质的产品？
BODY 秋天皮肤特别乾燥，有小皮屑怎么办？



me0624

卷首语
从CROSSOVER到COLLABORATIONS

iBlog爱博客
编辑博客大公开

iNews爱新货
2006秋冬10大流行风格预览

iFashion爱服装
夏装秋穿
夏季连衣裙变身时髦秋装4大法

iStar爱明星
时尚名人STYLE教学~
I爱Skinny Jeans超窄裤

iStyle爱造型
美体穿衣手册
腿粗怎么选裙子

iBeauty爱美容
我要当个小脸美人

iFitness爱健身
爱美丽一分钟瘦身操:
UP！UP！健胸操

iNews爱新货
初秋肌肤去角质大扫除

iMag爱杂志
必看流行杂志推推推

iTaro爱塔罗
你的另一半是真心爱你的吗?
塔罗星座双周报

iTest爱测验
叶子心理测验～个性漂浮指数大检测

iQA爱发问
BEAUTY画眼线有什么技巧？
BODY有没有公认最好的减肥方法？


me0623

卷首语
时尚界大吹亚洲风

iBlog爱博客
编辑博客大公开

iNews爱新货
换季必备超尺寸大包包

iFashion爱服装
小气BUY金女超省钱计划
6件单品36变

iStar爱明星
时尚名人STYLE教学~
腰带就是要「粗」

iStyle爱造型
美体穿衣手册
夏季选择一款美型上衣

iBeauty爱美容
甜美发饰配戴要决
夏日清爽发速成班

iFitness爱健身
爱美丽一分钟瘦身操:
窈窕细腰伸展操

iNews爱新货
夏日纤体计划

iMag爱杂志
必看流行杂志推推推

iTaro爱塔罗
恋爱二选一
塔罗星座双周报

iTest爱测验
冰品心理测验～我的爱情敏感度

iQA爱发问
BEAUTY 不想做手术怎么去眼袋呢？
BODY 鸡蛋减肥法到底怎么样？


me0622

卷首语
PIN-UP GIRL风潮

iBlog爱博客
编辑博客大公开

iNews爱新货
夏日超靓坡跟鞋

iFashion爱服装
职场Fashion Show
柔美派 VS 乾练派OL搭配精选

iStar爱明星
时尚名人STYLE教学~
迷你连衣裙露腿秀

iStyle爱造型
美体穿衣手册
增高5cm的穿衣法则

iBeauty爱美容
夏日护足美足秘籍

iFitness爱健身
爱美丽一分钟瘦身操:
轻松减臂操

iNews爱新货
「睫」然不同

iMag爱杂志
必看流行杂志推推推

iTaro爱塔罗
家人反对的爱情要怎么办呢?
塔罗星座双周报

iTest爱测验
牛仔裤心理测验: 我的放松指数

iQA爱发问
酸奶当面膜能美白吗？
胸部特别大而且有点下垂，怎么减胸?


me0621

卷首语

iBlog爱博客
编辑博客大公开

iNews爱新货
迷你魅力无法挡

iFashion爱服装
穿出2006夏季热门派系
浪漫女人风VS可爱小姐风上衣宝典

iStar爱明星
时尚名人STYLE教学~
最IN指甲彩绘

iStyle爱造型
美体穿衣手册
牛仔裤拯救不完美腿型

iBeauty爱美容
拒绝油光光的脸
夏季控油大作战

iFitness爱健身
爱美丽一分钟瘦身操:
告别萝卜腿紧实操！

iNews爱新货
我的彩妆不怕水

iMag爱杂志
必看流行杂志推推推

iTaro爱塔罗
塔罗星座双周报

iTest爱测验
游泳心理测验～我的好强指数

iQA爱发问
白天保湿夜晚美白对吗？
有什么方法可以瘦小腿呢？


me0620

卷首语
时尚 × 运动风还是HOT~

iBlog爱博客
编辑博客大公开

iNews爱新货
现代和风流行秀

iFashion爱服装
运动服也fashion!
运动Mix时尚完全搭配手册!

iStyle爱造型
美体穿衣手册
抢救粗腰穿衣法

iStar爱明星
时尚名人STYLE教学~
发箍COOL一夏

iBeauty爱美容
去海边、去郊游、去上班
防晒、晒后护理大行动！

iFitness爱健身
爱美丽一分钟瘦身操:
踢踢腿，翘臀跟着来！

iNews爱新货
夏季水果面膜秀

iMag爱杂志
必看流行杂志推推推

iTaro爱塔罗
跟前男友还有复合的机会吗?


me0619

卷首语

iBlog爱博客
编辑博客大公开

iNews爱新货
夏日花花世界

iFashion爱服装
夏日实用裙装课堂!
找到属于你的那一条本命裙!

iStyle爱造型
完全搭配手册
抢救平胸穿衣法

iStar爱明星
时尚名人STYLE教学~
夏日圣品: 人字拖

iBeauty爱美容
大家快来瘦身穿比基尼！
一次过丰胸、瘦腰、瘦大腿、瘦手臂

iFitness爱健身
爱美丽一分钟瘦身操
告别Bye Bye袖必做操

iNews爱新货
夏妆大玩金光闪闪

iMag爱杂志
必看流行杂志推荐

iTaro爱塔罗
嫁给他会幸福吗？
塔罗星座双周报

iTest爱测验
背包占卜＿我的花钱指数

iQA爱发问
短裤也可以搭配的很淑女吗？
鼻子上有很严重的黑头，用鼻贴可以吗？

因为已经很多期了,以前的介绍我就不更新了.
如果有最新期出来,我会进行内容介绍的!
PS:因为每周都要上课,基本上每天晚上8-12点左右我都会挂机,有时候也通宵挂驴子.
10M光纤,基本上挂驴子就有源.
不过因为要上课,每周有三天左右时间不回家,希望大家能够帮忙作源!

正版瑞星，18.45.21版本，2006-09-22病毒库杀毒无毒。
常驻DonkeyServer No1/DonkeyServer No2/DonkeyServer No3
另，因为最近要在外地上课，更新时间在周末。下载完的朋友请帮忙续源，谢谢~

引用此页 (Trackback) (?)

Coding Horror: How to Write Technical Documentation - Mozilla Firefox

[webnote]

 

 

 

*

.NET and human factors by Jeff Atwood

« The Programmer's Bill of Rights | Main | The Sporkfe »

August 25, 2006

How to Write Technical Documentation

I was browsing around the CouchDb wiki yesterday when I saw Damien Katz' hilarious description of how technical documentation really gets written. You know, in the real world:

Welcome to the world of technical documentation!

The situation you are in is no different from any other tech writer. The technical writing process:

1. Ask engineer how the damn thing works.
2. Deafing silence.
3. Crickets.
4. Tumbleweed.
5. Just start writing something. Anything.
6. Give this something to the engineer.
7. Watch engineer become quite upset at how badly you've missed the point of everything.
8. As the engineer berates you, in between insults he will also throw off nuggets of technical information.
9. Collect these nuggets, as they are the only reliable technical information you will receive.
10. Try like hell to weave together this information into something enlightening and technically accurate.
11. Go to step 6.

Ok, you're not the doc writing type. That's okay, neither am I. However, people are already working to make this better, and I will continue to do so.

I think I've been on both ends of this exchange at some point in my career. It's funny because it's true. I'm sure I've read descriptions exactly like this on Mike Pope's blog.

Posted by Jeff Atwood at August 25, 2006 11:59 PM | TrackBack

Comments

The good tech writers I knew used an audio recorder for step 8.

Teman on August 27, 2006 03:32 PM

As a tech writer, I find it's a hell of a lot easier to take the program and figure out how it works myself.

Beth on August 27, 2006 05:18 PM

Heh, heh. We've been trying out having the developers scrawl some useful but geeky notes on the wiki once they finish on feature. The notes are details of the actual implementation that testers and tech writers might use to help get them started.

Seems to working not too bad so far.

Paul Norrie on August 27, 2006 05:48 PM

Sad but true. Of course, I would blame the developer since, if they have built something without any use cases, requirements or screen layouts that specify what that something is, then it is highly likely that what they have built won't do any non-technical user any good. Additionally, I'd blame the tech writer since, if the software is nearly complete and they have not raised any red flags about missing use cases or requirements then they have very clearly dropped the ball. And, of course, I blame management who consistently lets this happen over and over and over again.

One day at my last employer, who shall remain nameless - let's just call them the Pit of Hell, I was walking down one of the corridors and encountered one of my peers. I pointed at a nearby cubicle and said "That is what is wrong with this company". My peer stared at me in a very strange way - what could be wrong with a developer and a technical writer sitting in the developer's cube having a work related conversation? I've always thought the battle is lost when a developer and a technical writer are talking; the vast majority of the time, although they seem to be speaking English, in reality they have no common language.

Marketing literature is the same (if not worse). Another time at "The Pit", I read a press release for one of our soon to be released products; we'll call it Pixie Dust for sake of a name. I picked up a printed copy of this press release and walked over to my friend's office; she was the technical lead for Pixie Dust at the time. I asked her if she thought it strange that we had two products called Pixie Dust since this press release very clearly had nothing to do with the product she was building.

Tim Dudra on August 28, 2006 01:32 AM

I like the tumbleweed part....

xD

labrat on August 28, 2006 04:48 AM

Not sure why one would go to the developer? I prefer to play with the software myself, read/decipher business requirements and specs, and if all else fails, go to the business analyst, product manager, or whoever designed the thing and wrote the requirements/specs.

Lisa on August 28, 2006 11:08 AM

Let's just be honest here:

If you could really write, you'd be publishing your novel and polishing your pulitzer.

If you really understood computers/code, you'd be coding your own apps.

Armen on August 28, 2006 11:37 AM

Let's just be honest here Armen: Those are two incredibly stupid statements.

Firstly, just as there is a huge difference between writing GUI code and server code and test driver code, there is a huge difference between doing technical writing and fiction writing. I doubt J.R.R. Tolkein could have written good technical documentation and I can't imagine Steve McConnell (of Code Complete fame) pounding out a fantasy thriller.

Secondly, if someone wanted to code their own applications, why would they let something as unimportant as not really understanding computers/code get in their way? It hasn't stopped a significant percentage of software professionals.

With my tongue somewhat in my cheek,
Somewhat sincerely,
Tim

Tim Dudra on August 28, 2006 07:12 PM

Nice post. Thought provking.

Paul's approach is a good attempt. Seems to be working for him.

Lisa and Beth seem to have a can-do attitude to the situation.

This got a little long as I wrote it, and it's probably a bit off topic, but what the heck...

In a perfect world, specs would be frozen, use cases would be complete, and clients would be realistic in terms of cost and schedule. (Ha! If you live in that world, consider that you have a great job.)

In the real world that most of us inhabit, none of these is the case. Developers who can't, or more accurately, refuse to learn to write and speak coherently are the root of this problem. Let's be honest about the situation -- project managers, business analysts, tech writers, and clients aren't stupid. They just don't understand code, add we, as developers, shouldn't expect them to. It's our responsibility to help them with the technical intricacies that need further explanation.

I hear developers whine all of the time about crappy specs. It's almost as though developers expect a magical, frozen document to be produced that can be used as the basis for code specifications, technical documentation, user guides, marketing materials, etc., etc., etc. If that kind of document could be written, then what's the need for developers, tech writers, marketing, etc., etc., etc.??? The work is already done! It's a team effort, guys. We all need do our part.

If the spec is crap, don't write code against it until you clarify what you should do. ASK A QUESTION OR TWO. Understand what you are doing. If you don't understand the purpose of the feature you are writing, and you can't ask a sensible question, then I wonder what your real value is to your organization.

If all you want to do is code to spec, and you demand a *perfect* spec, and you're not willing to ask questions when what you've been asked to do doesn't make sense to you, then you've turned your job into EXACTLY the kind of menial work that is being outsourced to India in droves. Developers need STEP UP and become more useful and cooperative team members, or suffer the consequences.

And yes, I *am* a developer -- not a suit. I just refuse to put my name on something that I can not defend. If I don't know how (and why) it does what it does, pointing to a crappy spec doesn't help me -- it only hurts my co-workers (those PMs and BAs), who I should be supporting. Why would I want to set up a "me vs. them" situation?

Leave the egos at the door. Work for your team's success, or get the f--- out.

Jeff - but not that Jeff on August 28, 2006 07:23 PM

Let's be honest with Armen here:

If you could really write programs that worked properly, you wouldn't need a tech writer to tell your users what you really meant the program to do, and to tell them how to fix up the mess when it doesn't do it.

And if you think you do that already, that's because you can't write or talk to users, which is no great surprise.

Or if you could really code things properly, you could just write a compiler for the requirements specs and go home early the first time it happens. (No second time needed.)

PeterM on August 28, 2006 10:02 PM

Jeff,
I reckon the error lies right at the beginning, at step #1:
>>Ask engineer how the damn thing works.
Nope. Read through all the literature available: your specs, design docs, the whole thing BEFORE you approach the engineer. Which'll enable you to keep the engineer on guard because of your well-preparedness. I follow this. Works everytime, like a charm.

Tech writers looking for developers/engineers for help are kidding none but themselves, and then they complain "we're not respected."

Sandeep on August 28, 2006 10:31 PM

Hey Jeff - but not that Jeff! Great response. I agree completely except for one point. You say "I hear developers whine all of the time about crappy specs". Now, I've worked in just about every kind of job you can find in an R&D department so I have been a whiney developer, a sloppy spec writer, a tyrannical project manager, an ivory towered architect and I've dabbled in dreaming the impossible dream (product management) and I'm sure I'm missing some other stuff too. Heck, I'm even one up on Tolkein and McConnell in that I've done some technical writing that was fiction.

That said, when writing specs it was my honest opinion that many of our developers whined about the specs being incomplete if the work being spec'ed sounded boring, would require them to overhaul their existing Objects' d'Art, force them to interact with their peers or bothered them religiously. By whining and demanding "clearer specs" they could delay the odious work and hopefully have it dropped due to deadline pressures. On the other hand, if what was being spec'ed seemed interesting or fun, they were quite content to charge ahead with even the most minimal of specs (especially if the specs were so minimal they could interpret them however they wanted).

Now, before everyone thinks I'm bashing developers - program managers and product managers and QA people were all quick to bash the developers and often wouldn't initiate conversations with them because they would have to step outside their own comfort zone in trying to understand the technicalese. PMs would spec stuff that was very expensive or quite possibly NP-complete and get frustrated when the developers said "it can't be done". Of course, there was always the boy who cried wolf syndrome to be considered since the developers had already cried "it can't be done" three times already.

Peter, you're bang on too.

Tim Dudra on August 28, 2006 10:38 PM

So, is this we get documentation that explains the "WidgetMode" check box as "Enables WidgetMode"? No shit, really?

Doug on August 29, 2006 01:45 PM

I'm a technical writer. I think of my work as translating Geek to English. That's the job, guys; you do need to speak enough Geek to merit the "technical" part of the job description.

So while there are plenty of developers who make the tech writer's life a misery, there are also plenty of tech writers who need to work harder at their translation skills. And as several people noted, that means reading - and understanding - all the specs and design documents.

Molly O'Scribe on August 31, 2006 01:03 PM

If I relied on the so-called "specs" from the developers, I _would_ be a successful fiction writer.

Most times when I get tech/func specs from development, they are so full of implementation possibilites (we could do this... or we could do that) and commented questions, that oftimes, the only resemblance the own to the finished product is their name. Sometimes they are just enough to get the thing working and then we can write something worth using.

The times when we have worthless specs and must document from an app are frustrating and typically end with a few lines of fluff because it's impossible to drive the app without knowing how to setup the background data.

Some of my developer's produce decent specs to write from. Our app is extremely complex. There are probably not more than two or three people in the whole company who are proficient enough to demontrate all of its features (and that would take several days to do). These developer's are irreplaceable. Unfortuantely, there aren't many of them.

Trent The Thief on September 1, 2006 04:47 AM

Trent: I hope you have a decent editor.

I get really exercised when I find mistakes like these from people who are supposed to be making their living writing in English.

"the only resemblance the own"
they own

"how to setup"
set up

"Some of my developer's produce decent specs to write from."
Some of my developers produce [it would only be developer's produce if we're talking about carrots!] decent specs FROM WHICH TO WRITE.

"Unfortuantely"
Unfortunately [Okay, I'll give you this one; it's just a typo.]

molly o'scribe on September 4, 2006 05:45 PM

Name:


Website:


Enter the word



Your comments: (no HTML)

Content (c) 2006 Jeff Atwood. Logo image used with permission of the author. (c) 1993 Steven C. McConnell. All Rights Reserved.