精华内容
下载资源
问答
  • 关于环保环境的建议书 每一次走过马路,每一次经过的大街小巷里,都能看见穿环保服的背影。那么我们又能为环保做些什么呢?下面是小编整理的关于环保环境的建议书,欢迎阅读参考。关于环保环境的建议书篇1 相信每个...
  • 并且添加了环境变量 ![图片说明](https://img-ask.csdn.net/upload/202002/15/1581764537_877242.png) 这是我OpenCV头文件的目录,和配置中设置的一样: ![图片说明]...
  • 关于提问问题

    千次阅读 2012-04-08 09:33:08
    其实早就写篇关于提问的文章,但是一直瞎忙吧。一拖再拖,终于偷的半刻,来弄点东西。 其实学习的过程,不用我说,陌生的东西,刚开始大家接触慢慢接触,之后会有问题出现: 这个怎么跟xxx 不一样呀?诸如 这个...
    其实早就写篇关于提问的文章,但是一直瞎忙吧。一拖再拖,终于偷的半刻,来弄点东西。 
    
    其实学习的过程,不用我说,陌生的东西,刚开始大家接触慢慢接触,之后会有问题出现:
    这个怎么跟xxx 不一样呀?诸如 这个代码怎么过不去呀?有的干脆直接去百度,发帖,到群里去问别人。异或自己一直死磕着等等吧 有的去问还说跪求 ,寒冬中。。。。等等怎么来着,这些不都些扯淡的话吗?还不如把问题说的更详细些有用。那是否有人来回答你的问题呢?
    首先,记得一条:别人回答你的问题,是你的幸运。不管他的回答受否正确,你都应该说声谢谢。可能以前同样的问题,人家用了这样的方法解决了,但并不一定对你有用,但也许对你有提示,或许刚好能解决。“谢谢” 二字 虽说很容易,但却经常遗弃。别人回答你的问题只是别人的义务,他可回答也可不回答。他若没回答,你或许会用“什么耍大牌,大架子”之类的话,试问下他回答能得到什么“好处”(有点世俗了),更糟的是,求问者还会继续提写“弱智”的问题,当你是回答者时,你还会继续吗?我是不会了,倘若意味问别人,自己不思考,会越问越多。这是最可怕的。另说,经过思考后,认识到问题的缘由,慢慢的自己也会解决问题了。不用或很少再求别人了,恭喜你,你可以出师了。小说里的一个门派的创始人大凡不都是这样的?扯远了。而百度求答之类的悬“赏金币”的性质,虽说你们之间有“利益”(说的有点大)的联系 ,不过希望还是请你说声谢谢,同时也能体现你的素质嘛 !
    还有态度的问题!记着别人是在“帮”你解决问题!!!而不是你在帮别人回答问题!!!所以把你的“架子”之类的放下,“XXX,  来给我看看这个”他是你的物品吗?随叫随到?有篇古文叫东阳马生序的 看下 弟子请教夫子的态度,另一个天地!
    求问的方式,这个不用多说,提问的智慧 这么好的文章放在这里最合适不过了!



    提问的智慧


    作者:

    Eric Steven Raymond 

    Rick Moen 

    修订历史
    修订版 3.12004年10月28日esr
    文档‘Google 是你的朋友!’
    修订版 3.02004年2月2日esr
    主要增加网页论坛应有的礼节内容
    原文How To Ask Questions The Smart Way
    翻译:王刚 < yafrk@yahoo.com  >  
    时间:2004年11月2日

    译文

    译文: 捷克语 丹麦语 爱沙尼 亚语 法语 德语 希伯来语 匈牙利语 意大利语 日语 波 兰语 俄语 西班牙语 瑞典语 土 耳其语. 如果你想复制、镜像、翻译或引用本文,请参阅我的 复制须知

    弃权申明

    许多项目的网站在 如何取得帮助的部分链接了本文,这没有关系,也是我们想要的。但如果你是该项目生成此链接的网管,请在链接附近显著位置注明“我们不是此项目的服务部!

    我们已经遭受没有此说明带来的痛苦,不断受到一些白痴的骚扰。他们认为既然我们发表了此文,那么我们就有责任解决世上所有技术问题!

    如果你因为需要帮助阅读了本文,然后带着可以直接从作者那取得帮助的印象离开,你就不幸成了那些白痴之一。不要向我们提问,我们不会理睬 的。 我们在这只是给你说明如何从那些真正懂得你软硬件问题的人那里取得帮助的方法,99%的时间我们不会是那些人。除非你确信此文作者是你遇到问题方面的专 家, 请不要打扰,这样大家都更开心一点。

    引言

    在 黑客 的世界,你所提技术问题的回答很大程度上取决于你提问的方式与解决此问题的难度,本文将教你如何提问才更有可能得到满意的答复。

    开源程序的使用已经很广,你通常可以从其它更有经验的用户而不是黑客那里得到回答。这是好事,他们一般对新手常有的毛病更容忍一点。然尔,使用我们 介 绍的方法象对待黑客那样对待这些有经验的用户,通常能最有效地得到问题的解答。

    第一件需要明白的事是黑客喜欢难题和激发思考的好问题。假如不是这样,我们也不会写本文了。如果你能提出一个有趣的问题让我们咀嚼玩味,我们会感激 你。 好的 问题是种激励与礼物,帮助我们发展认知,揭示没有注意或想过的问题。在黑客中,“好问题!”是非常真挚的赞许。

    除此而外,黑客有遇到简单问题就表现出敌视或傲慢的名声,有时候我们看起来还对新手和愚蠢的家伙有条件反 射式的无礼,但并不真正是这样。

    我们只是毫无歉意地敌视那些提问前 不愿思考、不做自己该做之事的人。这种人就象时间无底洞──他们只知道获取,不愿意付出,他们浪费了时间,这些时间本可用于其它更值得回答的人和 更有趣 的问题。我们将这种人叫做“失败者 (loser)” (由于历史原因,我们有时将“loser”拼为“lusers")

    我们注意到许多人只想用我们写的软件,他们对学习技术细节没有兴趣。对大多数人而言,计算机只是种工具,是种达到目的的手段。他们要生活并且有更要 紧的事要做,我们承认这点,也从不指望每个人都对这些让我们着迷的技术问题感兴趣。不过,我们回答问题的风格是为了适应那些真正对此有兴趣并愿意主动参与 问题解决的 人,这一点不会变,也不该变。如果这都变了,我们就会在自己能做得最好的事情上不再那么犀利。

    我们(多数)是自愿者,从自己繁忙的生活中抽时间来回答问题,有时会力不从心。因此,我们会无情地滤除问题,特别是那些看起来象是失败者的,以 便更有效地把回答问题的时间留给那些“胜利者”

    如果你认为这种态度 令人憎恶、以施惠者自居或傲慢自大,请检查你的假设,我们并未要求你屈服──事实上,假如你做了该做的努力使之成为可能,我们中的 大多数人非常乐意平等地与你交流并欢迎你接纳我们的文化。试图去帮助那些不愿自救的人对我们简直没有效率,不懂没有关系,但愚蠢地行事不行。

    所以,你不必在技术上很在行才能吸引我们的注意,但你必须表现出能引导你在行的姿态──机 敏、思考、善于观察、乐于主动参与问题的解决。如果你 做不到这些使你与众不同的事情,我们建议你付钱跟别人签商业服务合同,而不是要求黑客无偿帮助。

    如果你决定向我们求助,你不会想成为一名失败者,你也不想被看成一个失败者。得到快速有效回复的最好方法是使提问者看起来象个聪明、自 信的人,并且暗示只是碰巧在某一特别问题上需要帮助。

    (欢迎对本文指正,可以将建议发至 esr@thyrsus.com 。 请注意,本文不想成为一般性的 网络礼仪 指南,我一般会拒绝那些与引出技术论坛中有用的回复不特别相关的建议)

    提问前

    在通过电子邮件、新闻组或网页论坛提技术问题之前,做以下事情:

    1. 尝试搜索互联网以找到答案

    2. 尝试阅读手册以找到答案

    3. 尝试阅读FAQ(常见问题)文档以找到答案

    4. 尝试自己检查或试验以 找到答案

    5. 尝试请教懂行的朋友以找到答案

    6. 如果你是程序员,尝试阅读源代码以找到答案

    提问时,请先表述你已经做了上述事情,这将有助于建立你不是寄生虫与浪费别人时间的印象。最好再表述你从中学到的东西,我们喜欢 回答那些表现出能从答案中学习的人。

    使用某些策略,比如用Google搜索你遇到的错误提示(既搜索网页也查查讨论组),可能就直接找到了解决问题的文档或邮件列表线索。即使没有结 果,在电子邮件或新闻组张贴问题时提一句“我在Google中查过下列句子但没有找到什么有用的东西”也是件好事。

    准备你的问题,彻底地思考。轻率的提问只能得到轻率的回答,或者压根没有。在提问时,越是表现出做过思考并在努力解 决问题,你越有可能得到 实际帮助。

    注意别提错问题。如果提问基于错误的假设,某黑客多半会一边想”愚蠢的问题……“,一边用按照问题字面的无用答案回复你,并且希望这种只 是得到 字 面回答而不是真正所需的经历给你一个教训。

    永远不要假设你有资格得 到解答。你没有这种资格,毕竟你没有为此服务付费。如果你能够提出有内容、有趣和激励思考的问题──那种毫无疑问能够向社 区贡献经验而不仅仅是消极地要求从别人那获取知识的问题,你将“挣到”答案。

    另一方面,表明你能够也乐意参与问题的解决是个很好的开端。“有没有 人能指个方向?”、“我这还漏点什么?”、“我应该查哪些网站?”通常要比 “请给出我可以用的完整步骤”更容易得到回复,因为你表明了只要有人能指个方向你就很乐意完成剩下的过程。

    提问时

    仔细挑选论坛

    要对在哪提问留心,如果你做了下 述事情,多半会被一笔勾销或被看成“失败者”:

    • 张贴与论坛主题完全无关的问题

    • 在面向高级技术问题的论坛上提非常 初浅的问题,或者反之。

    • 在太多不同的新闻组同时交叉张贴

    • 给既非熟人也没有义务解决你问题的个人张贴你私人的电子邮件

    为保护通信的渠道不被无 关的东西淹没,黑客会除掉那些没有找对地方的问题,你不会想有这种经历的。

    所以第一步是找对论坛,Google与其它搜索引擎还是你的朋友,可以用它们搜索与你遇到困难的软硬件问题最相关的项目的网站。那 里通常都有项目的FAQ列表、邮件列表及其文档的链接。如果你的努力(包括阅读FAQ)都没有结果,这些邮件列表就是最后能取得帮助 的地方。项目的网站也许还有报告臭虫的流程或链接,如果是这样,去看看。

    向陌生的人或论坛发送邮件极有可能是在冒险。譬如,不要假设一个富含信息的网页的编写者想充当你的免费顾问,不要对你 的问题是否会受到欢迎做乐 观的 估计──如果你 不确定,向别处发或者根本别发。

    在选择网页论坛、新闻组或邮件列表时,不要太相信名字,先看看FAQ或者许可书以明确你的问题 是否与其主题相关。张贴前先翻翻已有的帖 子可 以 帮助你感受一下那里行事的方式。事实上,张贴之前在新闻组或邮件列表中搜索与你问题相关的关键词是个很好的主意,也许就找到答案了。即使没有,也能帮助你 整理 出 更好的问题。

    别象机关枪似的一次性“扫射”所有的帮助通 道,那就象大嚷大叫并使人不快。一个一个地来。

    弄清楚你的主题!最典型的错误之一是在某种致立于跨Unix和Windows平台的语言、库或工具的论坛中提关于操作系统程序接口的问题。如果你不 明白为什么这是大错,最好在搞清楚概念前什么也别问。

    一般来说,在仔细挑选的公共论坛中提问比在私有论坛中提同样的问题更容易得到有用的回复。有许多理由支持这一点,一是看潜在的回复者有多少,二是看 论 坛的参与者有多少,黑客更愿回答能启发多数人的问题。

    可以理解,老练的黑客和一些流行软件的作者正在收到超出他们承受能力的不当消息。就象那根多出来就可以压垮骆驼背的稻草一样,你的 加入也可能会使情况走向极端──已经好几次了,一些流行软件的作者退出了对其软件的支持,因为伴随而来的涌向其私人邮箱的大量无用消息变得无法 忍受。

    面向新手的网页论坛和IRC通常响应最快

    本地的用户组织或者你所用的Linux发行版也许正在宣传新手取得帮助的网页论坛或IRC(互联网中继聊天) (在非英语国家,新手论坛很可能还是邮件列表),这些 地 方 是开始提问的好去处,尤其是当你觉得遇到的也许只是相对简单或者一般的问题时。经过宣传的IRC通道是个公开邀请提问的地方,通常可以得到实时的回复。

    事实上,如果出问题的程序来自某发行版(这很常见),在程序的项目论坛或列表提问前最好先在发行版的论坛或列表中问问,(否则)项目的黑客可能仅仅 回复“用我们代码”

    在任何网页论坛张贴之前,先看看是否有搜索功能。如果有,就试试用问题的几个关键词搜索一下,也许就有帮助。如果在此之前你已做过全面的网页搜索 (你应该这样做),还是再搜索一下论坛,搜索引擎最近也许还没有索引此论坛的全部内容。

    通过网页论坛或IRC频道提供项目的用户支持有增长的趋势,电子邮件交流则更多地为项目开发保留。先在网页论坛或IRC中寻求与项目相关的帮 助。

    第二步,使用项目邮件列表

    当某项目存在开发者邮件列表时,即使你确信谁能最好地回答问题,也要向列表而不是其中的个体提问。检查项目的文档和主页,找到项目的邮件列表并使 用它。采用这种策略有几个好理由:

    • 任何向单个开发者提的足够好的问题也将对整个项目组有益。相反,如果你认为自己的问题对整个项目组来说太愚蠢,这也不能成为打扰 单个开发者的理由。

    • 向列表提问可以平衡开发者的负担,单个开发者(特别是项目领导)也许太忙以至于无法回答你的问题。

    • 大多数邮件列表有历史文档并被搜索引擎索引,其它人可以通过网页搜索找到你的问题和答案而不用再次在邮件列表中发问。

    • 如果某些问题经常被问到,开发者可以利用此信息改进文档或软件本身以使其更清楚。如果只是私下提问,就没有人能看到最常见问题的完整 场景。

    如果一个项目既有“用户”也有“开发者”(或“黑客”)邮件列表或网页论坛,而你又不摆弄那些代码,向“用户”列表或论坛提问。不要假设自己在开发 者列表中会受欢 迎,那些人多半会遭受你的噪音干扰。

    然尔,如果你确信你的问题不一般,而且在“用户” 列表或论坛中几天都没有回复,可以试试“开发者”列表或论坛。建议你在张贴前最好先暗暗地观察几天 以了解那的行事方式(事实上这是参与任何私有或半私有列表的好主意)

    如果你找不到一个项目的邮件列表,而只能查到项目维护者的地址,只管向其发信。即便在这种情况下,也别假设(项目)邮件列表不存在。在你的电子邮 件中陈述你已 经试过但没有找到合适的邮件列表,也提及你不反对将自己的邮件转发给他人(许多人认为,即使没什么秘密,私人电子邮件也不应该被公开。通过允许将你的电子 邮件 转 发他人给 了相应人员处置你邮件的选择)。

    使用明确而有意义的主题

    在邮件列表、新闻组或网页论坛中,主题是你在五十个或更少的字符以内吸引有资格的专家注意的黄金机会,不要用诸如“请帮我”(更别提大写的“请帮 我!!!!”,这种主题的消息会被条件反射式地删掉)之类的唠叨浪费机会。不要用你痛苦的深度来打动我们,相反,要在这点空间中使用超级简明扼要的问题 描述。

    使用主题的好惯例是“对象──偏差”(式的描述),许多技术支持组织就是这样做的。在“对象”部分指明是哪一个或哪一组东西有问题,在“偏差”部分 则描述与期望 行 为不一致的地方。


    愚蠢:

    救命啊!我的笔记本视频工作不正常!


    明智:

    XFree86 4.1扭曲鼠标光标,某显卡MV1005型号的芯片组


    更明智:

    使用某显卡MV1005型号芯片组的XFree86 4.1的鼠标光标被扭曲

    编写“对象──偏差”式描述的过程有助于你更具体地组织你的问题。是什么被影响了?仅仅是鼠标光标或者还有其它图形?只在XFree86中出现?或 只是在其4.1版中?是针对某显卡?或者只是其MV1005型号的芯片组?一个黑客只需描一眼就能够立即明白什么是你遇到的问题,什么是你自己的问题。

    更一般地,想象一下在只显示主题的文档索引中查找。让你的主题更好地反映问题,可以使下一个搜索类似问题的人能够在文档中直接找到答案的线索而不用 再次张贴提问。

    如果你想在回复中提问,确保改变主题以表明你是在问一个问题,一个主题象“re: 测试”或“re: 新臭虫”的消息不太可能引起足够的注意。同 时,将回复中与新主题不甚相关的引用内容尽量删除

    对于列表消息,不要直接点击回复(按钮)来开始一个新的线索,这将限制你的观众。有些邮件阅读程序,比如mutt,允许用户按线索排序并通过折叠线 索来隐藏消息, 这样做的人永远看不到你发的消息。

    仅仅改变主题还不够。mutt和其它邮件阅读程序还要检查主题以外的其它邮件头信息,以便为其指定线索,所以宁可发一 个全 新的邮件。

    在网页论坛,因为消息与特定的线索紧密结合并且通常在线索之外不可见,好的提问方式略有不同,通过回复提问并不要紧(一些论坛甚至不允许在 回复中出现分离的主题,而且这样做了基本上没有人会去看)。不过通过回复提问本身就是令人怀疑的做法,因为它们只会被正在查看该 线索的人读到。所以,除非你只想在该线索当前活跃的人群中提问,还是另起炉灶比较好。

    使之更易回复

    以“请向……回复”来结束问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦,我们也觉得花几秒钟 考虑你的问题更麻烦。如果你的邮件客户端程序不支持这样做,换个好点的。如果是操作系统不支持所有这种邮件客户端程序,也换个好点的。

    在网页论坛,要求通过电子邮件回复是完全无礼的,除非你确信回复的信息也许是机密的(而且有人会为了某种未知的原因只让你而不是整个论坛知道答 案)。如果 你只是想 在有人回复线索时得到电子邮件提醒,可以要求论坛发送。几乎所有论坛都提供诸如“留意本线索”、“有回复发送邮件”的功能。

    使用清晰、语法与拼写正确的语句

    经验告诉我们,粗心与草率的作者通常也粗心与草率地思考和编程(我敢打赌)。为这些粗心与草率的思考者回答问题没有什么好处,我们宁可将 时间花在其它地方。

    清楚、完整地表达你的问题非常重要。如果你觉得这样做麻烦,我们也觉得注意(你的问题)麻烦。花点额外的精力斟酌一下字句,用不着太僵硬与正式──事实 上,黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它必须很准确,而且有迹象表明你是在思考和关 注问题。

    正确地拼写、使用标点和大小写,不要将“its”混淆为“it's”,“loose”搞成“lose”或者将“discrete”弄成 “discreet”。不要全部用大写,这会被看成无礼的大声嚷嚷 (全部小写也好不到哪去,因为不易阅读。Alan Cox[注:著名黑客,Linux内核的重要参与者]也许可以这样做,但你不行 )。

    一般而言,如果你写得象个半文盲似的傻子,多半得不到理睬。如果象个小孩似地乱写乱画那绝对是在找死,可以肯定没人会理你(或者最多 是给你一大堆指责与挖苦)。

    如果在非母语论坛中提问,你的拼写与语法错误会得到有限的宽容,但懒惰完全不会被容忍(是的,我们通常看得出其中的差别)。同时,除非你知道回复者 使用 的语言,请使用 英语书写。繁忙的黑客一般会直接删除用他们看不懂语言写的消息。在互联网上英语是工作语言,用英语书写可以将你的问题不被 阅读就被直接删除的可能降到最低。

    使用易懂的格式发送问题

    如果你人为地将问题搞得难以阅读,它多半会被忽略,人们更愿读易懂的问题,所以:

    • 使用文本而不是HTML(超文本标注语言) ( 关闭HTML 并不难)

    • 使用MIME(多用途互联网邮件扩展)附件通常没有问题,前提是真正有内容(譬如附带的源文件或补丁),而不仅仅是邮件客户端程序 生 成的模板(譬如只是消息内容的拷贝)。

    • 不要发送整段只是单行句子但多次折回的邮件(这使得回复部分内容非常困难)。设想你的读者是在80个字符宽的文本终端阅读邮件, 设置你的行折回点小于80列。

    • 但是,也不要用 任何固定列折回数据(譬如直接传送的日 志文件或会话记录)。数据应该原样包含,使回复者确信他们看到的与你看到的东西一样。

    • 在英语论坛中,不要使用'Quoted-Printable' MIME编码发送消息。这种编码对于张贴非ASCII语言可能是必须的,但很多邮件代理程序并不支持。当它们分断时,那些文本中四处散布 的 “=20”符号既难看也分散注意力。

    • 永远不要指 望黑客们阅读使用封闭的专用格式编写的文档,诸如微软公司的Word或Excel文件等,大多数黑客对此的反应就象有人将还在冒热气的猪 粪倒在你门口时你的反应一样。即使他们能够处理,他们也很厌恶这么做。

    • 如果你从使用视窗的电脑发送电子邮件,关闭微软愚蠢的“聪明引用”功能,以免在你的邮件中到处散布垃圾字符。

    • 在网页论坛,勿滥用“表情符号”和“html”功能(当它们提供时)。一两个表情符号通常没有问题,但花哨的彩色文本倾向于使人认为 你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来象个傻笑的小姑娘。这通常不是个好主意,除非你只是对性而不是有用的回复更有兴趣。

    如果你使用图形用户界面的邮件客户端程序(如网景公司的Messenger、微软公司的Outlook或者其它类似的),注意它们的缺省配置不一 定满足这些要求。大多数这类程序有基于菜单的“查看源码”命令,用它来检查发送文件夹中的消息,以确保发送的是没有多余杂质的纯文本文件。

    描述问题应准确且有内容

    • 仔细、清楚地描述问题的症状

    • 描述问题发生的环境(主机,操作系统,应用程序,任何相关的),提供销售商的发行版和版本号(如:“Fedora Core 2”、“Slackware 9.1”等)

    • 描述提问前做过的研究及其理解。

    • 描述提问前为确定问题而采取的诊断步骤。

    • 描述最近对计算机或软件配置的任何相关改变。

    尽最大努力预测黑客会提到的问题,并提前备好答案。

    Simon Tatham写过一篇叫 如何有效报告臭虫 的文章,我强烈推荐各位阅读。

    多不等于准确

    你应该(写得)准确且有内容,简单地将一大堆代码或数据“倾倒”在求助消息中达不到目的。如果你有一个很大且复杂的测试样例让程序崩溃,尝 试将其裁剪得越小越好。

    至少有三个理由支持这点。第一,让别人看到你在努力简化问题使你更有可能得到回复。第二,简化问题使你更有可能得到有用的回复。第三,在提纯臭虫 报告的过程中,你可能自己就找到了解决问题的方法或权宜之计。

    别动辄声称找到臭虫

    当你在一个软件中遇到问题,除非你非 常、非常的有根据,不要动辄声称找到了臭虫。提示:除非你能提供解决问题的源代码补丁,或者对前一版本的回归测 试 表现出不正确的行为,否则你都多半不够完全确信。对于网页和文档也如此,如果你(声称)发现了文档的“臭虫”,你应该能提供相应位置的替代文本。

    记住,还有许多其它用户未经历你遇到的问题,否则你在阅读文档或网页搜索时就应该发现了(你在报怨前已经做了这些,是吧?)。这也意味着很有可能是你弄错了而不是软件本身有问 题。

    编写软件的人通常非常辛苦地使它尽可能完美。如果你声称找到了臭虫,也就暗示他们做错了什么,而这几乎总会使人不快──即使你是对的, 在主题中嚷嚷“臭虫”也是特别不老练的。

    提问时,即使你私下非常确信已经发现一个真正的臭虫,最好写得象是做 错了什么。如果真的有臭虫,你会在回复中看到这点。这么做的话,如果真有虫子,维护者就会向你道歉,这总比你弄 砸了然后欠别人一个道歉要强。

    低声下气不能代替自己应做之事

    有些人明白他们不应该粗鲁或傲慢地行事并要求得到答复,但他们退到相反的低声下气的极端,“我知道我只是个什么也不是、什么也不懂的失败者, 但……”。这既使人困扰也没有帮助,当伴随着对实际问题含糊的描述时还特别令人反感。

    别用低级灵长类动物的策略浪费大家的时间,相反,尽量清楚地表述背景事实和你的问题,这比低声下气更好地摆正了你的位置。

    有时,网页论坛设有单独的初学者提问区域,如果你真的认为遇到了初浅的问题,到那去就是了,但一样别低声下气。

    描述问题症状而不是猜测

    告诉黑客你认为是什么导致了问题是没有用的(如果你的诊断理论是了不起的东西,你还会向他人咨询求助吗?)。所以,确保只是告诉他们问题的原始 症状,而不是你的解释和理论,让他们来解释和诊断。如果你认为陈述你的猜测很重要,清楚地说明这只是你的猜测并描述为什么它们不起作用。


    愚蠢:

    我在编译内核时接连遇到SIG11错误,怀疑主板上的某根电路丝断了,找到它们的最好办法是什么?

    明智:

    我组装的电脑(K6/233 CPU、FIC-PA2007主板(威盛Apollo VP2芯片组)、Corsair PC133 SDRAM 256Mb内 存)最近在开机20分钟左右、做内核编译时频繁地报SIG11错,但在头20分钟内从不出问题。重启动不会复位时钟,但整夜关机会。更换所有内存未解决问 题,相关的典型编译会话日志附后。

    按时间先后罗列症状

    刚出问题之前发生的事情通常包含有解决问题最有效的线索。所以,记录中应准确地描述你及电脑在崩溃之前都做了些什么。在命令行处理的 情况下,有会话日志(如运行脚本工具生成的)并引用相关的若干(如20)行记录会非常有帮助。

    如果崩溃的程序有诊断选项(如-v详述选项),仔细考虑选择这些能在记录中增加排错信息的选项。

    如果你的记录很长(如超过四段),也许在开头简述问题随后按时间先后罗列详细过程更有用。这样做,黑客在读你的记录时就知道该查哪些内容了。

    描述目的而不是步骤

    如果你想弄清楚如何做某事(而不是报告一个臭虫),在开头就描述你的目标,此后才描述为此采取的措施所遇到的问题。

    经常有这种情况,寻求技术帮助的人在脑袋里有个更高层面的目标,他们在自以为能达到目标的特定道路上被卡住了,然后跑来问该怎么走,但 没有意识到这条路本身有问题,结果要费很大的劲才能通过。

    愚蠢:

    我怎样才能让某图形程序的颜色拾取器取得十六进制的RGB值?

    明智:

    我正试图用自己选定数值的颜色替换一幅图片的颜色表,我现在唯一知道的方法是编辑每个表槽,但却无法让某图形程序的颜色拾取器取得十六进 制的RGB值。

    第二种提法是明智的,它使得建议采用更合适的工具完成任务的回复成为可能。

    别要求私下回复

    黑客们认为问题的解决过程应该公开、透明,此过程中如果更有才能的人注意到不完整或者不当之处,最初的回复才能够、也应该被更正。同时,作为 回复者也因为能力和学识被其它同行看到而得到某种回报。

    当你要求私下回复时,此过程和回报都被中止。别这样做,让回复者来决定是否私下回答──如果他 真这么做了,通常是因为他认为问题编写太差或者太肤浅 以 至于对其它人无意义。

    对这条规则存在一条有限的例外,如果你确信提问可能会导致大量雷同的回复时,那么“给我发电子邮件,我将为小组归纳这些回复”将是神奇的句子。试图 将邮 件列表或新闻组从洪水般雷同的回复中解救出来是非常有礼貌的──但你应信守诺言。

    问题应明晰

    漫无边际的问题通常也被视为没有明确限制的时间无底洞。最有可能给你有用答案的人通常也是最忙的人(假如只是因为他们承担了大多数工作的话),这些 人 对于没 有限制的时间无底洞极其反感,所以他们也倾向于讨厌那些漫无边际的问题。

    如果你明确了想让回复者做的事(如指点方向、发送代码、检查补丁或其它),你更有可能得到有用的回复。这可以使他们集中精力并间接地设定了他们为帮 助你需要花费的时间和精力上限,这很好。

    要想理解专家生活的世界,可以这样设想:那里有丰富的专长资源但稀缺的响应时间。你暗中要求他们奉献的时间越少,你越有可能从这些真正懂行也真正很 忙的专家 那里得到回答。

    所以限定你的问题以使专家回答时需要付出的时间最少──这通常还与简化问题不一样。举个例,“请问可否指点一下哪有好一点的X解释?”通常要 比“请解释一下X”明智。如果你有什么代码不运行了,通常请别人看看哪有问题比叫他们帮你改正更明智。

    别张贴家庭作业

    黑客们善于发现“家庭作业”式的问题。我们大多数人已经做了自己的家庭作业,那是该你做的,以便从其经历中学习。问一 下提示没有关系,但不是要求完整的解决方案。

    如果你怀疑自己碰到了一个家庭作业式的问题,但仍然无法解决,尝试在用户组论坛或(作为最后一招)在项目的“用户”邮件列表或论坛中提问。尽管 黑客们会看出来,一些高级用户也许仍会给你提示。

    删除无意义的问题

    抵制在求助消息末尾加上诸如“有人能帮我吗?”或“有没有答案?”之类在语义上无任何意义东西的诱惑。第一,如果问题描述还不完整,这些附 加的东西最多也只能是多余的。第二,因为它们是多余的,黑客们会认为这些东西烦人──就很有可能用逻辑上无误但打发人的回复,诸如“是的,你可 以得到帮助”和“不,没有给你的帮助”

    一般来说,避免提“是或否”类型的问题,除非你想得到 “是或否”类型的回答

    不要刻意标明问题紧急

    这是你自己的问题,不要我们的。宣称“紧急”极有可能事与愿违:大多数黑客会直接删除这种消息,他们认为这是无礼和自私地企图得到即时与特殊的关 照。

    有一点点局部的例外,如果你是在一些知名度很高、会使黑客们激动的地方使用程序,也许值得这样去做。在这种情况下,如果你有期限压力,也很有礼貌 地提到这点,人们也许会有足够的兴趣快一点回答。

    当然,这是非常冒险的,因为黑客们对什么是令人激动的标准多半与你的不同。譬如从国际空间站这样张贴没有问题,但代表感觉良好的慈善或政治原 因这样做几乎肯定不行。事实上,张贴诸如“紧急:帮我救救这个毛绒绒的小海豹!”肯定会被黑客回避或光火,即使他们认为毛绒绒的小海豹很重要。

    如果你觉得这不可思议,再把剩下的内容多读几遍,直到弄清楚了再发贴。

    礼貌总是无害的

    礼貌一点,使用“请”和“谢谢你的关注”或者“谢谢你的意见”,让别人明白你感谢他们无偿花时间帮助你。

    坦率地说,这一点没有语法正确、文字清晰、准确、有内容和避免使用专用格式重要(同时也不能替代它们)。黑客们一般宁可读有点唐突但技术鲜明的臭 虫报告,而不是那种礼貌但含糊的报告。(如果这点让你不解,记住我们是按问题能教我们些什么来评价一个问题的)

    然尔,如果你已经谈清楚了技术问题,客气一点肯定会增加你得到有用回复的机会。

    (我们必须指出,本文唯一受到一些老黑客认真反对的地方是以前曾经推荐过的“提前谢了”,一些黑客认为这隐含着事后不用再感谢任何人的暗示。我们的 建议是 先说 “提前谢了”,事后再对回复者表示感谢。或者换种方式表达,譬如用“谢谢你的关注”或“谢谢你的意见”)。

    问题解决后追加一条简要说明

    问题解决后向所有帮助过的人追加一条消息,让他们知道问题是如何解决的并再次感谢。如果问题在邮件列表或新闻组中受到广泛关注,在那里追加此消息比 较恰当。

    最理想的方式是向最初提问的线索回复此消息并在主题包含“已解决”、“已搞定”或其它同样意思的明显标记。在人来人往的邮件列表里,一个看见线索 “问题X”和“问题X-已解决”的潜在回复者就明白不用再浪费时间了(除非他个人觉得“问题X”有趣),因此可以用此时间去解决其它 问题。

    你追加的消息用不着太长太复杂,一条简单的“你好──是网线坏了!谢谢大家──比尔”就比什么都没有要强。事实上,除  非解决问题的技术真正高深,一条简短而亲切的总结比长篇大论要好。说明是什么行动解决了问题,用不着重演整个排错的故事。

    对于有深度的问题,张贴排错历史的摘要是适当的。描述问题的最终状态,说明是什么解决了问题,在此之后才指明可以避免的弯路。应避免的 弯路部分应放在正确的解决方案和其它总结材料之后,而不要将此消息搞成侦探推理小说。列出那些帮助过你的名字,那样你会交到朋友的。

    除了有礼貌、有内容以外,这种类型的追帖将帮助其他人在邮件列表、新闻组或论坛文档中搜索到真正解决你问题的方案,从而也让他们受益。

    除上述而外,此类追帖还让每位参与协助的人因问题的解决而产生一种满足感。如 果你自己 不是技术专家或黑客,相信我们,这种感觉对于你寻求帮助的老手和专家非常重要。问题叙述到最后不知所终总是令人沮丧的,黑客们痒 痒地渴望看到它们被解决。“挠痒痒”为你挣到的好报将对你下次再次张贴提问非常非常的有帮助。

    考虑一下怎样才能避免其他人将来也遇到类似的问题,问问自己编一份文档或FAQ补丁有没有帮助,如果有的话就将补丁发给维护者。

    在黑客中,这种行为实际上比传统的礼貌更重要,也是你善待他人而赢得声誉的方式,这是非常有价值的财富。

    如何解读回答

    RTFM和STFW:如何知道你已完全搞砸

    有一个古老而神圣的传统:如果你收到了“RTFM”的回复,发信人认为你应该去“读读该死的手册”。他多半是对的,去读一下吧。

    RTFM有个年轻的亲戚,如果你收到“STFW”的回复,发信人认为你应该“搜搜该死的网络”。他多半也是对的,去搜一下吧。(更温和一点的说法是 “Google 是你的朋友!”)

    在网页论坛,你也可能被要求去搜索论坛的文档。事实上,有人甚至可能热心地为你提供以前解决此问题的线索。但不要依赖这种好心,提问前应先搜索 一下文 档。

    通常,叫你搜索的人已经打开了能解决你问题的手册或网页,正在一边看一边敲键盘。这些回复意味着他认为:第一,你要的信息很容易找到。第二,自已找 要比别人喂到嘴里能学得更多。

    你不应该觉得这样就被冒犯了,按黑客的标准,他没有不理你就是在向你表示某种尊敬,你反而应该感谢他热切地想帮助你。

    如果还不明白

    如果你看不懂回复,不要马上回发一个要求说明的消息,先试试那些最初提问时用过的同样工具(手册、FAQ,网页、懂行的朋友等)试着搞懂回 复。如果还是需要说明,展现你已经明白的。

    譬如,假如我告诉你:“听起来象是某输入项有问题,你需要清除它”,接着是个不好的回帖:“什么是某输入项?”。 而这是一个的跟帖:“是 的, 我读了手册,某输入项只在-z和-p开关中被提到,但都没有提及清除某选项,你指的是哪一个还是我弄错了什么?”

    对待无礼

    很多黑客圈子中看似无礼的行为并不是存心冒犯。相反,它是直接了当、一刀见血式的交流风格,这种风格对于更关注解决问题而不是使别人感觉舒服而混乱 的人 是很自然的。

    你如果觉得被冒犯,努力平静地反应。如果有人真的做了过格的事,邮件列表或新闻组或论坛中的前辈多半会招呼他。如果这没有发生而你却发火了,那么你发火对 象的言语 可能在黑客社区中看起来是正常的,而将 被视为有错的一方,这将伤害到你获取信息或帮助的机会。

    另一方面,你会偶而真的碰到无礼和无聊的言行。与上述相反,对真正的冒犯者狠狠地打击、用犀利的语言将其驳得体无完肤都是可以 接受的。然尔,在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔,黑客们自己莽撞地越线情况并不鲜见。如果你是新 手或外来者,避开这种莽撞的机会不高。如果你 想得到的是信息而不是消磨时光,这时最好不要把手放在键盘上以免冒险。

    (有些人断言很多黑客都有轻度的自闭症或阿斯伯格综合症,一定缺少平滑人类社会“正常”交往所需的脑电路。这既可能是真也可能是假。如果你自己不是 黑客,兴许 你认为我 们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了,我们不在乎。我们喜欢我们现在这个样子,并且一般都对 临床诊断有相当的怀疑。)

    在下一节,我们会谈到另一个问题,当你行为不当时会受到的“冒犯”

    别象个失败者那样反应

    在黑客社区的论坛中有那么几次你会搞砸──以本文详述或类似的方式。你会被示众是如何搞砸的,也许言语中还会带点颜色。

    这种事发生以后,你能做的最糟的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等 等。相 反,你该这样去做:

    熬过去,这很正常。事实上,它是有益健康与恰当的。

    社区的标准不会自己维持,它们是通过参与者积极而公开地执行来维持的。不要哭嚎所有的 批评都应该通过私下的邮件传送,这不是事情运作的方式。当有人批评你的 一些主张或者其看法不同时,坚持声称个人被侮辱也毫无用处,这些都是失败者的态度。

    也有其它的黑客论坛,受太高礼节要求的误导,要求参与者禁止张贴任何对别人帖子挑毛病的消息,并被告知“如果你不想帮助用户就闭嘴”。有思路的参与 者纷纷 离 开 的结果只会使它们变成了毫无意义的唠叨与无用的技术论坛。

    是夸张的“友谊”(以上述方式)还是有用?挑一个。

    记住:当黑客说你搞砸了,并且(无论多么刺耳地)告诉你别再这样做时,他正在为关心你和他的社区而行动。对他而言,不理你并将你从他的生活中滤除要 容易得 多。如果你无法做到感谢,至少要有点尊严,别大声哀嚎,也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者,就指望别人象对待脆弱的洋娃娃 那样对你。

    有时候,即使你没有搞砸(或者只是别人想象你搞砸了), 有些人会无缘无故地攻击你本人。在这种情况下,报怨倒是真的会把问题搞砸。

    这些找茬者要么是什么也不懂但自以为是专家的不中用家伙,要么就是测试你是否真会搞砸的心理学家。其它读者要么不理睬,要么用自己的方式对付他们。 这些找茬者在给自己找麻烦,这点你不用操心。

    也别让自己卷入口水战,大多数口水战最好不要理睬──当然是在你核实它们只是口水战、没有指出你搞砸的地方,而且没有巧妙地将问题真正的答案藏于其 中 (这也 是 可能的)之后。

    提问禁忌

    下面是些典型的愚蠢问题和黑客不回答它们时的想法。

    问:   我到哪可以找到程序或X资源? 问:   我怎样用X做Y? 问:   如何配置我的shell提示? 问:   我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格式 吗? 问:   我的{程序、配置、SQL语句}不运行了 问:   我的视窗电脑出问题了,你能帮忙吗? 问:   我的程序不运行了,我认为系统工具X有问题 问:   我安装Linux或X遇到困难,你能帮忙吗? 问:   我如何才能破解超级用户口令/盗取频道操作员的特权/查看某人的电子邮件?
    问:

    我到哪可以找到程序或X资源?

    答:

    在我找到它的同样地方,笨旦──在网页搜索引擎上。上帝啊,难道还有人不知道如何使用 Google 吗?

    问:

    我怎样用X做Y?

    答:

    如果你想做的是Y,提问时别给出可能并不恰当的方法。这种问题说明提问者不但对X完全无知,也对要解决的Y问题糊涂,还被特定形势禁 锢了思维。等他们把问题弄 好再说。

    问:

    如何配置我的shell提示?

    答:

    如果你有足够的智慧提这个问题,你也该有足够的智慧去 RTFM, 然后自己去找。

    问:

    我可以用Bass-o-matic文件转换工具将AcmeCorp文档转为TeX格 式吗?

    答:

    试试就知道了。如果你试过,你既知道答案,又不用浪费我的时间了。

    问:

    我的{程序、配置、SQL语句}不运行了

    答:

    这不是一个问题,我也没有兴趣去猜你有什么问题──我有更要紧的事要做。看到这种东西,我的反应一般如下:

    • 你还有什么补充吗?

    • 噢,太糟了,希望你能搞定。

    • 这跟我究竟有什么关系?

    问:

    我的视窗电脑出问题了,你能帮忙吗?

    答:

    是的,把视窗垃圾删了,装个象Linux或BSD的开源操作系统吧。

    注意:如果程序有官方的视窗版或与视窗有交互(如Samba),你可以问与视窗电脑相关的问题,只是别 对问题是由视窗操作系统而不是程序本身造成的回复感 到惊讶,因 为视窗一般来说太差,这种说法一般都成立。

    问:

    我的程序不运行了,我认为系统工具X有问题

    答:

    你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与库文件有明显缺陷的人,更有可能的是你完全没有根据。不同凡响的说法需 要不同凡响的证据, 当你这样 声称时,你必须有清楚而详尽的缺陷说明文档作后盾。

    问:

    我安装Linux或X遇到问题,你能帮忙吗?

    答:

    不行,我需要亲手操作你的电脑才能帮你排错,去向当地的Linux用户组寻求方便的帮助(你可以在 这里 找到用户组列表)

    注意:在为某一Linux发行版服务的邮件列表或论坛或本地用户组织中提关于安装该发行版的问题也许是恰当的。此时,应描述问题的准确 细节。在此之前,先用 “linux”和所有被怀 疑的硬件(为关键词)仔细搜索。

    问:

    我如何才能破解超级用户口令/盗取频道操作员的特权/查看某人的电子邮件?

    答:

    想做这种事情说明你是个卑劣的家伙,想让黑客教你做这种事情说明你是个白痴。

    好问题与坏问题

    最后,我将通过举例来演示提问的智慧。同样的问题两种问法,一种愚蠢,另一种明智。


    愚蠢:我在哪能找到关于Foonly Flurbamatic设备的东西?

    这个问题在乞求得到 STFW 式的回复。


    明智:我用Google搜索过“Foonly Flurbamatic 2600”,但没有找到什么有用的,有谁知道在哪能找到这种设备的编程信息?

    这个人已经搜索过网络了,而且听起来他可能真的遇到了问题。


    愚蠢:我不能编译某项目的源代码,它为什 么这么破?

    他假设是别人搞砸了,太自大了。


    明智:某项目的源代码不能在某Linux 6.2版下编译。我读了常见问题文档,但其中没有与某Linux相关的问题。这是编译时的记录,我做错了什么吗?

    他指明了运行环境,读了FAQ,列出了错误,也没有假设问题是别人的过错,这家伙值得注意。


    愚蠢:我的主板有问题,谁能帮我?

    某黑客对此的反应可能是:“是的,还需要帮你拍背和换尿布吗?”,然后是敲下删除键。


    明智:我在S2464主板上试过X、Y和 Z,当它们都失败后,又试了A、B和C。注意我试C时的奇怪症状,显然某某东西正在做某某事情,这不是期望的。通常 在Athlon MP主板上导致某某事情的原因是什么?有谁知道我还能再试点什么以确定问题?

    相反地,这个人看来值得回答。他展现了解决问题的能力而不是坐等天上掉馅饼。

    在最后那个问题中,注意“给我一个回复”与“请帮我看看我还能再做点什么测试以得到启发”之间细微但重要的差别。

    事实上,最后那个问题基本上源于2001年8月Linux内核邮件列表(lkml)上的真实事件,是我(Eric)当时提了那个问题,我发现 Tyan S2462 主板有神秘的死机现象,邮件列表成员给我提供了解决此问题的关键信息。

    通过这种提问方式,我给了别人可以咀嚼玩味的东西。我设法使之对参与者既轻松又有吸引力,也表明了对同行能力的尊敬并邀请他们与我一起协商。通 过告诉 他们我已经走过的弯路,我还表明了对他们宝贵时间的尊重。

    事后,当我感谢大家并评论这次良好的经历时,一个Linux内核邮件列表的成员谈到,他认为并不是因为我的名字在列表上,而是因为我正确的提问方式 才 得到了答 案。

    黑客们在某种方面是非常不留情面的精英分子。我想他是对的,如果我表现得象个不劳而获的寄生虫,不管我是谁都会被忽略或斥责。他建议将整个事件作为 对其它 人 提问的指导直接导致了本文的编写。

    如果没有回复

    如果得不到回答,请不要认为我们不想帮你,有时候只是因为小组成员的确不知道答案。没有回复不等于被忽略,当然必须承认从外面很难看出两者的差别。

    一般来说,直接将问题再张贴一次不好,这会被视为毫无意义的骚扰。

    还有其它资源可以寻求帮助,通常是在一些面向新手的资源中。

    有许多在线与本地用户组织,虽然它们自己不编写任何软件,但是对软件很热心。这些用户组通常因互助和帮助新手而形成。

    还有众多大小商业公司提供签约支持服务(红帽与Linuxcare是两家最出名的,还有许多其它的)。别因为要付点钱才有支持就感到沮丧!毕竟,如 果你车子的 汽缸垫烧了,你多半还得花钱找个修理店把它弄好。即使软件没花你一分钱,你总不能指望服务支持都是免费的。

    象Linux这样流行的软件,每个开发者至少有一万个以上的用户,一个人不可能应付这么多用户的服务要求。记住,即使你必须付费才能得到支持,也比 你还得额外花钱买软件要少得多(而且对封闭源代码软件的服务支持与开源软件相比通常还要贵一点,也要差一点)

    如何更好地回答 问题

    态度和善一点。问题带来的压力常使人 显得无礼或愚蠢,其实并不是这样。

    对初犯者私下回复。对那些坦诚犯错 之人没有必要当众羞辱,一个真正的新手也许连怎么搜索或在哪找FAQ都不知道。

    如果你不确定,一定要说出来!一个听 起来权威的错误回复比没有还要糟,别因为听起来象个专家好玩就给别人乱指路。要谦虚和诚实,给提问者与同行都树个好榜样。

    如果帮不了忙,别妨 碍。不要在具体步骤上开玩笑,那样也许会毁了用户的安装──有些可怜的呆瓜会把它当成真的指令。

    探索性的反问以引出更多的细节。如 果你做得好,提问者可以学到点东西──你也可以。试试将很差的问题转变成好问题,别忘了我们都曾是新手。

    尽管对那些懒虫报怨一声RTFM是正当的,指出文档的位置(即使只是建议做个Google关键词搜索)会更好。

    如果你决意回答,给 出好的答案。当别人正使用错误的工具或不当 的方法时别建议笨拙的权宜之计,应推荐更好的工具,重新组织问题。

    帮助你的社区从问题中 学习。当回复一个好问题时,问问自己 “如何修改相关文件或FAQ文档以免再次解答同样的问题?”,接着再向文档维护者发一份补丁。

    如果你的确是在研究一番后才做出的回答,展 现你的技巧而不是直接端出结果。毕竟“授 人以鱼,不如授人以渔”

    展开全文
  • Android开发环境搭建时下载了Google官方 的 Android studio还需要下载SDK和ADT吗?
  • 关于python中conda环境的激活问题

    万次阅读 2019-09-02 22:35:32
    报错信息如下 首先查看Anaconda的安装路径 输入命令 conda env list ...然后激活环境 首先输入 activate+你的路径 出现base说明已经进入环境 在输入conda activate base 然后测试 已经没有警告啦!哈哈 ...

    报错信息如下

    警告信息

    首先查看Anaconda的安装路径

    第一步:
    输入 conda env list
    base后面即为安装的路径

    第二步:
    输入 conda activate + 你的路径
    输入python测试
    在这里插入图片描述

    上述是一次激活的方法

    Anaconda 是自带python环境的,和你安装的python是两个独立的python环境,当你使用的是anaconda prompt默认进入的是anaconda的python环境(因为我这里没有创建其他环境,只有一个),这个环境是本来就已经激活过的,而你使用cmd进入的并不是anaconda那个已经激活的环境,所以需要使用命令进入Anaconda中已经激活的环境也就是那个base。

    现提出一个更为简洁的方法,使用别名激活

    第一步:
    在C盘下创建一个.bat文件
    文件内容为你需要使用别名的信息
    在这里插入图片描述
    当你输入actan时相当于执行conda activate E:\Anaconda3这条命令

    第二步:

    • win + R 输入regedit,进入注册表编辑器进入计算机\HKEY_CURRENT_USER\Software\Microsoft\Command
      Processor(一开始你可能找不到Command Processor这个文件夹,所以你需要自己创建)
    • 右键"新建"->字符串值->双击即可进行编辑,这里的数值名称随便,但是数值数据为你在C盘下创建的那个文件的路径
    • 最后保存计科

    2
    最后进行一下测试:
    输入别名即可进入环境 actan
    2

    展开全文
  • 提问的智慧: 如何适当的提出问题

    千次阅读 2019-10-09 15:34:26
    本文适用于,当看见一些令人气愤的想骂"你不会百度吗"之类的问题时,直接甩出发给对方的场景本文节选自Github:https://github.com/ryanhanwu/...

    本文适用于,当看见一些令人气愤的想骂"你不会百度吗"之类的问题时,直接甩出发给对方的场景

    640?wx_fmt=png

    本文节选自

    Github:

    https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/master/README-zh_CN.md

    640?wx_fmt=png

    在提问之前

    在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前,请先做到以下事情:

    1. 尝试在你准备提问的论坛的旧文章中搜索答案。

    2. 尝试上网搜索以找到答案。

    3. 尝试阅读手册以找到答案。

    4. 尝试阅读常见问题文件(FAQ)以找到答案。

    5. 尝试自己检查或试验以找到答案。

    6. 向你身边的强者朋友打听以找到答案。

    7. 如果你是程序开发者,请尝试阅读源代码以找到答案。

    当你提出问题的时候,请先表明你已经做了上述的努力;这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好,因为我们更乐于回答那些表现出能从答案中学习的人的问题。

    运用某些策略,比如先用 Google 搜索你所遇到的各种错误信息(既搜索 Google 论坛,也搜索网页),这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果,在邮件列表或新闻组寻求帮助时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西 也是件好事,即使它只是表明了搜索引擎不能提供哪些帮助。这么做(加上搜索过的字串)也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。

    别着急,不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前,再阅读一下常见问题文件(FAQ)、放轻松、坐舒服一些,再花点时间思考一下这个问题。相信我们,他们能从你的提问看出你做了多少阅读与思考,如果你是有备而来,将更有可能得到解答。不要将所有问题一股脑拋出,只因你的第一次搜索没有找到答案(或者找到太多答案)。

    准备好你的问题,再将问题仔细的思考过一遍,因为草率的发问只能得到草率的回答,或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力,你越有可能得到实质性的帮助。

    小心别问错了问题。如果你的问题基于错误的假设,某个普通黑客(J. Random Hacker)多半会一边在心里想着蠢问题…, 一边用无意义的字面解释来答复你,希望着你会从问题的回答(而非你想得到的答案)中汲取教训。

    绝不要自以为够格得到答案,你没有;你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案,靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题,而不仅仅是被动的从他人处索取知识。

    另一方面,表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示?我的这个例子里缺了什么?以及我应该检查什么地方请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向,你就有完成它的能力和决心。

    当你提问时

    慎选提问的论坛

    小心选择你要提问的场合。如果你做了下述的事情,你很可能被忽略掉或者被看作失败者:

    • 在与主题不合的论坛上贴出你的问题。

    • 在探讨进阶技术问题的论坛张贴非常初级的问题;反之亦然。

    • 在太多的不同新闻群组上重复转贴同样的问题(cross-post)。

    • 向既非熟人也没有义务解决你问题的人发送私人电邮。

    黑客会剔除掉那些搞错场合的问题,以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。

    因此,第一步是找到对的论坛。再说一次,Google 和其它搜索引擎还是你的朋友,用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题(FAQ)、邮件列表及相关说明文件的链接。如果你的努力(包括阅读 FAQ)都没有结果,网站上也许还有报告 Bug(Bug-reporting)的流程或链接,如果是这样,链过去看看。

    向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说,别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 -- 如果你不确定,那就向别处发送,或者压根别发。

    在选择论坛、新闻群组或邮件列表时,别太相信名字,先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题,这样可以让你感受一下那里的文化。事实上,事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意,也许这样就找到答案了。即使没有,也能帮助你归纳出更好的问题。

    别像机关枪似的一次"扫射"所有的帮助渠道,这就像大喊大叫一样会使人不快。要一个一个地来。

    搞清楚你的主题!最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错,最好在搞清楚这之间差异之前什么也别问。

    一般来说,在仔细挑选的公共论坛中提问,会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点,一是看潜在的回复者有多少,二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。

    可以理解的是,老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样,你的加入也有可能使情况走向极端 —— 已经好几次了,一些热门软件的作者从自己软件的支持中抽身出来,因为伴随而来涌入其私人邮箱的无用邮件变得无法忍受。

    Stack Overflow

    搜索,然后 在 Stack Exchange 问。

    近年来,Stack Exchange community 社区已经成为回答技术及其他问题的主要渠道,尤其是那些开放源码的项目。

    因为 Google 索引是即时的,在看 Stack Exchange 之前先在 Google 搜索。有很高的机率某人已经问了一个类似的问题,而且 Stack Exchange 网站们往往会是搜索结果中最前面几个。如果你在 Google 上没有找到任何答案,你再到特定相关主题的网站去找。用标签(Tag)搜索能让你更缩小你的搜索结果。

    Stack Exchange 已经成长到超过一百个网站,以下是最常用的几个站:

    • Super User 是问一些通用的电脑问题,如果你的问题跟代码或是写程序无关,只是一些网络连线之类的,请到这里。

    • Stack Overflow 是问写程序有关的问题。

    • Server Fault 是问服务器和网管相关的问题。

    网站和 IRC 论坛

    本地的使用者群组(user group),或者你所用的 Linux 发行版本也许正在宣传他们的网页论坛或 IRC 频道,并提供新手帮助(在一些非英语国家,新手论坛很可能还是邮件列表), 这些地方是开始提问的好首选,特别是当你觉得遇到的也许只是相对简单或者很普通的问题时。有广告赞助的 IRC 频道是公开欢迎提问的地方,通常可以即时得到回应。

    事实上,如果程序出的问题只发生在特定 Linux 发行版提供的版本(这很常见),最好先去该发行版的论坛或邮件列表中提问,再到程序本身的论坛或邮件列表提问。(否则)该项目的黑客可能仅仅回复 "用我们的版本"。

    在任何论坛发文以前,先确认一下有没有搜索功能。如果有,就试着搜索一下问题的几个关键词,也许这会有帮助。如果在此之前你已做过通用的网页搜索(你也该这样做),还是再搜索一下论坛,搜索引擎有可能没来得及索引此论坛的全部内容。

    通过论坛或 IRC 频道来提供使用者支持服务有增长的趋势,电子邮件则大多为项目开发者间的交流而保留。所以最好先在论坛或 IRC 中寻求与该项目相关的协助。

    在使用 IRC 的时候,首先最好不要发布很长的问题描述,有些人称之为频道洪水。最好通过一句话的问题描述来开始聊天。

    第二步,使用项目邮件列表

    当某个项目提供开发者邮件列表时,要向列表而不是其中的个别成员提问,即使你确信他能最好地回答你的问题。查一查项目的文件和首页,找到项目的邮件列表并使用它。有几个很好的理由支持我们采用这种办法:

    • 任何好到需要向个别开发者提出的问题,也将对整个项目群组有益。反之,如果你认为自己的问题对整个项目群组来说太愚蠢,也不能成为骚扰个别开发者的理由。

    • 向列表提问可以分散开发者的负担,个别开发者(尤其是项目领导人)也许太忙以至于没法回答你的问题。

    • 大多数邮件列表都会被存档,那些被存档的内容将被搜索引擎索引。如果你向列表提问并得到解答,将来其它人可以通过网页搜索找到你的问题和答案,也就不用再次发问了。

    • 如果某些问题经常被问到,开发者可以利用此信息来改进说明文件或软件本身,以使其更清楚。如果只是私下提问,就没有人能看到最常见问题的完整场景。

    如果一个项目既有"使用者" 也有"开发者"(或"黑客")邮件列表或论坛,而你又不会动到那些源代码,那么就向"使用者"列表或论坛提问。不要假设自己会在开发者列表中受到欢迎,那些人多半会将你的提问视为干扰他们开发的噪音。

    然而,如果你确信你的问题很特别,而且在"使用者" 列表或论坛中几天都没有回复,可以试试前往"开发者"列表或论坛发问。建议你在张贴前最好先暗地里观察几天以了解那里的行事方式(事实上这是参与任何私有或半私有列表的好主意)

    如果你找不到一个项目的邮件列表,而只能查到项目维护者的电子邮件地址,尽管向他发信。即使是在这种情况下,也别假设(项目)邮件列表不存在。在你的电子邮件中,请陈述你已经试过但没有找到合适的邮件列表,也提及你不反对将自己的邮件转发给他人(许多人认为,即使没什么秘密,私人电子邮件也不应该被公开。通过允许将你的电子邮件转发他人,你给了相应人员处置你邮件的选择)。

    使用有意义且描述明确的标题

    在邮件列表、新闻群组或论坛中,大约 50 字以内的标题是抓住资深专家注意力的好机会。别用喋喋不休的帮帮忙跪求(更别说救命啊!!!!这样让人反感的话,用这种标题会被条件反射式地忽略)来浪费这个机会。不要妄想用你的痛苦程度来打动我们,而应该是在这点空间中使用极简单扼要的描述方式来提出问题。

    一个好标题范例是目标 —— 差异式的描述,许多技术支持组织就是这样做的。在目标部分指出是哪一个或哪一组东西有问题,在差异部分则描述与期望的行为不一致的地方。

    蠢问题:救命啊!我的笔记本电脑不能正常显示了!

    聪明问题:X.org 6.8.1 的鼠标光标会变形,某牌显卡 MV1005 芯片组。

    更聪明问题:X.org 6.8.1 的鼠标光标,在某牌显卡 MV1005 芯片组环境下 - 会变形。

    编写目标 —— 差异 式描述的过程有助于你组织对问题的细致思考。是什么被影响了? 仅仅是鼠标光标或者还有其它图形?只在 X.org 的 X 版中出现?或只是出现在 6.8.1 版中? 是针对某牌显卡芯片组?或者只是其中的 MV1005 型号? 一个黑客只需瞄一眼就能够立即明白你的环境和你遇到的问题。

    总而言之,请想像一下你正在一个只显示标题的存档讨论串(Thread)索引中查寻。让你的标题更好地反映问题,可使下一个搜索类似问题的人能够关注这个讨论串,而不用再次提问相同的问题。

    如果你想在回复中提出问题,记得要修改内容标题,以表明你是在问一个问题, 一个看起来像 Re: 测试 或者 Re: 新 bug 的标题很难引起足够重视。另外,在不影响连贯性之下,适当引用并删减前文的内容,能给新来的读者留下线索。

    对于讨论串,不要直接点击回复来开始一个全新的讨论串,这将限制你的观众。因为有些邮件阅读程序,比如 mutt ,允许使用者按讨论串排序并通过折叠讨论串来隐藏消息,这样做的人永远看不到你发的消息。

    仅仅改变标题还不够。mutt 和其它一些邮件阅读程序还会检查邮件标题以外的其它信息,以便为其指定讨论串。所以宁可发一个全新的邮件。

    在网页论坛上,好的提问方式稍有不同,因为讨论串与特定的信息紧密结合,并且通常在讨论串外就看不到里面的内容,故通过回复提问,而非改变标题是可接受的。不是所有论坛都允许在回复中出现分离的标题,而且这样做了基本上没有人会去看。不过,通过回复提问,这本身就是暧昧的做法,因为它们只会被正在查看该标题的人读到。所以,除非你只想在该讨论串当前活跃的人群中提问,不然还是另起炉灶比较好。

    使问题容易回复

    请将你的回复发送到……来结束你的问题多半会使你得不到回答。如果你觉得花几秒钟在邮件客户端设置一下回复地址都麻烦,我们也觉得花几秒钟思考你的问题更麻烦。如果你的邮件程序不支持这样做,换个好点的;如果是操作系统不支持这种邮件程序,也换个好点的。

    在论坛,要求通过电子邮件回复是非常无礼的,除非你认为回复的信息可能比较敏感(有人会为了某些未知的原因,只让你而不是整个论坛知道答案)。如果你只是想在有人回复讨论串时得到电子邮件提醒,可以要求网页论坛发送给你。几乎所有论坛都支持诸如追踪此讨论串有回复时发送邮件提醒等功能。

    用清晰、正确、精准并语法正确的语句

    我们从经验中发现,粗心的提问者通常也会粗心的写程序与思考(我敢打包票)。回答粗心大意者的问题很不值得,我们宁愿把时间耗在别处。

    正确的拼写、标点符号和大小写是很重要的。一般来说,如果你觉得这样做很麻烦,不想在乎这些,那我们也觉得麻烦,不想在乎你的提问。花点额外的精力斟酌一下字句,用不着太僵硬与正式 —— 事实上,黑客文化很看重能准确地使用非正式、俚语和幽默的语句。但它必须很准确,而且有迹象表明你是在思考和关注问题。

    正确地拼写、使用标点和大小写,不要将its混淆为it'sloose搞成lose或者将discrete弄成discreet。不要全部用大写,这会被视为无礼的大声嚷嚷(全部小写也好不到哪去,因为不易阅读。Alan Cox 也许可以这样做,但你不行)。

    更白话的说,如果你写得像是个半文盲[译注:小白],那多半得不到理睬。也不要使用即时通信中的简写或火星文,如将简化为d会使你看起来像一个为了少打几个键而省字的小白。更糟的是,如果像个小孩似地鬼画符那绝对是在找死,可以肯定没人会理你(或者最多是给你一大堆指责与挖苦)。

    如果在使用非母语的论坛提问,你可以犯点拼写和语法上的小错,但决不能在思考上马虎(没错,我们通常能弄清两者的分别)。同时,除非你知道回复者使用的语言,否则请使用英语书写。繁忙的黑客一般会直接删除用他们看不懂语言写的消息。在网络上英语是通用语言,用英语书写可以将你的问题在尚未被阅读就被直接删除的可能性降到最低。

    如果英文是你的外语(Second language),提示潜在回复者你有潜在的语言困难是很好的: [译注:以下附上原文以供使用]

    English is not my native language; please excuse typing errors.

    • 英文不是我的母语,请原谅我的错字或语法。

    If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question.

    • 如果你说某语言,请寄信/私讯给我;我需要有人协助我翻译我的问题。

    I am familiar with the technical terms, but some slang expressions and idioms are difficult for me.

    • 我对技术名词很熟悉,但对于俗语或是特别用法比较不甚了解。

    I've posted my question in $LANGUAGE and English. I'll be glad to translate responses, if you only use one or the other.

    • 我把我的问题用某语言和英文写出来,如果你只用一种语言回答,我会乐意将其翻译成另一种。

    使用易于读取且标准的文件格式发送问题

    如果你人为地将问题搞得难以阅读,它多半会被忽略,人们更愿读易懂的问题,所以:

    • 使用纯文字而不是 HTML (关闭 HTML 并不难)。

    • 使用 MIME 附件通常是可以的,前提是真正有内容(譬如附带的源代码或 patch),而不仅仅是邮件程序生成的模板(譬如只是信件内容的拷贝)。

    • 不要发送一段文字只是一行句子但自动换行后会变成多行的邮件(这使得回复部分内容非常困难)。设想你的读者是在 80 个字符宽的终端机上阅读邮件,最好设置你的换行分割点小于 80 字。

    • 但是,对一些特殊的文件不要设置固定宽度(譬如日志档案拷贝或会话记录)。数据应该原样包含,让回复者有信心他们看到的是和你看到的一样的东西。

    • 在英语论坛中,不要使用Quoted-Printable MIME 编码发送消息。这种编码对于张贴非 ASCII 语言可能是必须的,但很多邮件程序并不支持这种编码。当它们处理换行时,那些文本中四处散布的=20符号既难看也分散注意力,甚至有可能破坏内容的语意。

    • 绝对,永远不要指望黑客们阅读使用封闭格式编写的文档,像微软公司的 Word 或 Excel 文件等。大多数黑客对此的反应就像有人将还在冒热气的猪粪倒在你家门口时你的反应一样。即便他们能够处理,他们也很厌恶这么做。

    • 如果你从使用 Windows 的电脑发送电子邮件,关闭微软愚蠢的智能引号功能 (从[选项] > [校订] > [自动校正选项],勾选掉智能引号单选框),以免在你的邮件中到处散布垃圾字符。

    • 在论坛,勿滥用表情符号HTML功能(当它们提供时)。一两个表情符号通常没有问题,但花哨的彩色文本倾向于使人认为你是个无能之辈。过滥地使用表情符号、色彩和字体会使你看来像个傻笑的小姑娘。这通常不是个好主意,除非你只是对性而不是对答案感兴趣。

    如果你使用图形用户界面的邮件程序(如微软公司的 Outlook 或者其它类似的),注意它们的默认设置不一定满足这些要求。大多数这类程序有基于选单的查看源代码命令,用它来检查发送文件夹中的邮件,以确保发送的是纯文本文件同时没有一些奇怪的字符。

    精确地描述问题并言之有物

    • 仔细、清楚地描述你的问题或 Bug 的症状。

    • 描述问题发生的环境(机器配置、操作系统、应用程序、以及相关的信息),提供经销商的发行版和版本号(如:Fedora Core 4Slackware 9.1等)。

    • 描述在提问前你是怎样去研究和理解这个问题的。

    • 描述在提问前为确定问题而采取的诊断步骤。

    • 描述最近做过什么可能相关的硬件或软件变更。

    • 尽可能的提供一个可以重现这个问题的可控环境的方法。

    尽量去揣测一个黑客会怎样反问你,在你提问之前预先将黑客们可能遇到的问题回答一遍。

    以上几点中,当你报告的是你认为可能在代码中的问题时,给黑客一个可以重现你的问题的环境尤其重要。当你这么做时,你得到有效的回答的机会和速度都会大大的提升。

    Simon Tatham 写过一篇名为《如何有效的报告 Bug》的出色文章。强力推荐你也读一读。

    话不在多而在精

    你需要提供精确有内容的信息。这并不是要求你简单的把成堆的出错代码或者资料完全转录到你的提问中。如果你有庞大而复杂的测试样例能重现程序挂掉的情境,尽量将它剪裁得越小越好。

    这样做的用处至少有三点。 第一,表现出你为简化问题付出了努力,这可以使你得到回答的机会增加; 第二,简化问题使你更有可能得到有用的答案; 第三,在精炼你的 bug 报告的过程中,你很可能就自己找到了解决方法或权宜之计。

    别动辄声称找到 Bug

    当你在使用软件中遇到问题,除非你非常、非常的有根据,不要动辄声称找到了 Bug。提示:除非你能提供解决问题的源代码补丁,或者提供回归测试来表明前一版本中行为不正确,否则你都多半不够完全确信。这同样适用在网页和文件,如果你(声称)发现了文件的Bug,你应该能提供相应位置的修正或替代文件。

    请记得,还有许多其它使用者没遇到你发现的问题,否则你在阅读文件或搜索网页时就应该发现了(你在抱怨前已经做了这些,是吧?)。这也意味着很有可能是你弄错了而不是软件本身有问题。

    编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug,也就是在质疑他们的能力,即使你是对的,也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有Bug时,这尤其严重。

    提问时,即使你私下非常确信已经发现一个真正的 Bug,最好写得像是你做错了什么。如果真的有 Bug,你会在回复中看到这点。这样做的话,如果真有 Bug,维护者就会向你道歉,这总比你惹恼别人然后欠别人一个道歉要好一点。

    低声下气不能代替你的功课

    有些人明白他们不该粗鲁或傲慢的提问并要求得到答复,但他们选择另一个极端 —— 低声下气:我知道我只是个可悲的新手,一个撸瑟,但...。这既使人困扰,也没有用,尤其是伴随着与实际问题含糊不清的描述时更令人反感。

    别用原始灵长类动物的把戏来浪费你我的时间。取而代之的是,尽可能清楚地描述背景条件和你的问题情况。这比低声下气更好地定位了你的位置。

    有时网页论坛会设有专为新手提问的版面,如果你真的认为遇到了初学者的问题,到那去就是了,但一样别那么低声下气。

    描述问题症状而非你的猜测

    告诉黑客们你认为问题是怎样造成的并没什么帮助。(如果你的推断如此有效,还用向别人求助吗?),因此要确信你原原本本告诉了他们问题的症状,而不是你的解释和理论;让黑客们来推测和诊断。如果你认为陈述自己的猜测很重要,清楚地说明这只是你的猜测,并描述为什么它们不起作用。

    蠢问题

    我在编译内核时接连遇到 SIG11 错误, 我怀疑某条飞线搭在主板的走线上了,这种情况应该怎样检查最好?

    聪明问题

    我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU(威盛 Apollo VP2 芯片组), 256MB Corsair PC133 SDRAM 内存,在编译内核时,从开机 20 分钟以后就频频产生 SIG11 错误, 但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用,但是关机一晚上就又能工作 20 分钟。 所有内存都换过了,没有效果。相关部分的标准编译记录如下…。

    由于以上这点似乎让许多人觉得难以配合,这里有句话可以提醒你:所有的诊断专家都来自密苏里州。 美国国务院的官方座右铭则是:让我看看(出自国会议员 Willard D. Vandiver 在 1899 年时的讲话:我来自一个出产玉米,棉花,牛蒡和民主党人的国家,滔滔雄辩既不能说服我,也不会让我满意。我来自密苏里州,你必须让我看看。) 针对诊断者而言,这并不是一种怀疑,而只是一种真实而有用的需求,以便让他们看到的是与你看到的原始证据尽可能一致的东西,而不是你的猜测与归纳的结论。所以,大方的展示给我们看吧!

    按发生时间先后列出问题症状

    问题发生前的一系列操作,往往就是对找出问题最有帮助的线索。因此,你的说明里应该包含你的操作步骤,以及机器和软件的反应,直到问题发生。在命令行处理的情况下,提供一段操作记录(例如运行脚本工具所生成的),并引用相关的若干行(如 20 行)记录会非常有帮助。

    如果挂掉的程序有诊断选项(如 -v 的详述开关),试着选择这些能在记录中增加调试信息的选项。记住,不等于。试着选取适当的调试级别以便提供有用的信息而不是让读者淹没在垃圾中。

    如果你的说明很长(如超过四个段落),在开头简述问题,接下来再按时间顺序详述会有所帮助。这样黑客们在读你的记录时就知道该注意哪些内容了。

    描述目标而不是过程

    如果你想弄清楚如何做某事(而不是报告一个 Bug),在开头就描述你的目标,然后才陈述重现你所卡住的特定步骤。

    经常寻求技术帮助的人在心中有个更高层次的目标,而他们在自以为能达到目标的特定道路上被卡住了,然后跑来问该怎么走,但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。

    蠢问题

    我怎样才能从某绘图程序的颜色选择器中取得十六进制的的 RGB 值?

    聪明问题

    我正试着用替换一幅图片的色码(color table)成自己选定的色码,我现在知道的唯一方法是编辑每个色码区块(table slot), 但却无法从某绘图程序的颜色选择器取得十六进制的的 RGB 值。

    第二种提问法比较聪明,你可能得到像是建议采用另一个更合适的工具的回复。

    别要求使用私人电邮回复

    黑客们认为问题的解决过程应该公开、透明,此过程中如果更有经验的人注意到不完整或者不当之处,最初的回复才能够、也应该被纠正。同时,作为提供帮助者可以得到一些奖励,奖励就是他的能力和学识被其他同行看到。

    当你要求私下回复时,这个过程和奖励都被中止。别这样做,让回复者来决定是否私下回答 —— 如果他真这么做了,通常是因为他认为问题编写太差或者太肤浅,以至于对其它人没有兴趣。

    这条规则存在一条有限的例外,如果你确信提问可能会引来大量雷同的回复时,那么这个神奇的提问句会是向我发电邮,我将为论坛归纳这些回复。试着将邮件列表或新闻群组从洪水般的雷同回复中解救出来是非常有礼貌的 —— 但你必须信守诺言。

    清楚明确的表达你的问题以及需求

    漫无边际的提问是近乎无休无止的时间黑洞。最有可能给你有用答案的人通常也正是最忙的人(他们忙是因为要亲自完成大部分工作)。这样的人对无节制的时间黑洞相当厌恶,所以他们也倾向于厌恶那些漫无边际的提问。

    如果你明确表述需要回答者做什么(如提供指点、发送一段代码、检查你的补丁、或是其他等等),就最有可能得到有用的答案。因为这会定出一个时间和精力的上限,便于回答者能集中精力来帮你。这么做很棒。

    要理解专家们所处的世界,请把专业技能想像为充裕的资源,而回复的时间则是稀缺的资源。你要求他们奉献的时间越少,你越有可能从真正专业而且很忙的专家那里得到解答。

    所以,界定一下你的问题,使专家花在辨识你的问题和回答所需要付出的时间减到最少,这技巧对你有用答案相当有帮助 —— 但这技巧通常和简化问题有所区别。因此,问我想更好的理解 X,可否指点一下哪有好一点说明?通常比问你能解释一下 X 吗?更好。如果你的代码不能运作,通常请别人看看哪里有问题,比要求别人替你改正要明智得多。

    询问有关代码的问题时

    别要求他人帮你调试有问题的代码,不提示一下应该从何入手。张贴几百行的代码,然后说一声:它不能工作会让你完全被忽略。只贴几十行代码,然后说一句:在第七行以后,我期待它显示 <x>,但实际出现的是 <y>比较有可能让你得到回应。

    最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例(bug-demonstrating test case)。什么是最精简的测试用例?那是问题的缩影;一小个程序片段能刚好展示出程序的异常行为,而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例?如果你知道哪一行或哪一段代码会造成异常的行为,复制下来并加入足够重现这个状况的代码(例如,足以让这段代码能被编译/直译/被应用程序处理)。如果你无法将问题缩减到一个特定区块,就复制一份代码并移除不影响产生问题行为的部分。总之,测试用例越小越好(查看话不在多而在精一节)。

    一般而言,要得到一段相当精简的测试用例并不太容易,但永远先尝试这样做的是种好习惯。这种方式可以帮助你了解如何自行解决这个问题 —— 而且即使你的尝试不成功,黑客们也会看到你在尝试取得答案的过程中付出了努力,这可以让他们更愿意与你合作。

    如果你只是想让别人帮忙审查(Review)一下代码,在信的开头就要说出来,并且一定要提到你认为哪一部分特别需要关注以及为什么。

    别把自己家庭作业的问题贴上来

    黑客们很擅长分辨哪些问题是家庭作业式的问题;因为我们中的大多数都曾自己解决这类问题。同样,这些问题得由你来搞定,你会从中学到东西。你可以要求给点提示,但别要求得到完整的解决方案。

    如果你怀疑自己碰到了一个家庭作业式的问题,但仍然无法解决,试试在使用者群组,论坛或(最后一招)在项目的使用者邮件列表或论坛中提问。尽管黑客们会看出来,但一些有经验的使用者也许仍会给你一些提示。

    去掉无意义的提问句

    避免用无意义的话结束提问,例如有人能帮我吗?或者这有答案吗?

    首先:如果你对问题的描述不是很好,这样问更是画蛇添足。

    其次:由于这样问是画蛇添足,黑客们会很厌烦你 —— 而且通常会用逻辑上正确,但毫无意义的回答来表示他们的蔑视, 例如:没错,有人能帮你或者不,没答案

    一般来说,避免用 是或否对或错有或没有类型的问句,除非你想得到是或否类型的回答。

    即使你很急也不要在标题写紧急

    这是你的问题,不是我们的。宣称紧急极有可能事与愿违:大多数黑客会直接删除无礼和自私地企图即时引起关注的问题。更严重的是,紧急这个字(或是其他企图引起关注的标题)通常会被垃圾信过滤器过滤掉 —— 你希望能看到你问题的人可能永远也看不到。

    有半个例外的情况是,如果你是在一些很高调,会使黑客们兴奋的地方,也许值得这样去做。在这种情况下,如果你有时间压力,也很有礼貌地提到这点,人们也许会有兴趣回答快一点。

    当然,这风险很大,因为黑客们兴奋的点多半与你的不同。譬如从 NASA 国际空间站(International Space Station)发这样的标题没有问题,但用自我感觉良好的慈善行为或政治原因发肯定不行。事实上,张贴诸如紧急:帮我救救这个毛绒绒的小海豹!肯定让你被黑客忽略或惹恼他们,即使他们认为毛绒绒的小海豹很重要。

    如果你觉得这点很不可思议,最好再把这份指南剩下的内容多读几遍,直到你弄懂了再发文。

    礼多人不怪,而且有时还很有帮助

    彬彬有礼,多用谢谢您的关注,或谢谢你的关照。让大家都知道你对他们花时间免费提供帮助心存感激。

    坦白说,这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要(也不能取而代之)。黑客们一般宁可读有点唐突但技术上鲜明的 Bug 报告,而不是那种有礼但含糊的报告。(如果这点让你不解,记住我们是按问题能教给我们什么来评价问题的价值的)

    然而,如果你有一串的问题待解决,客气一点肯定会增加你得到有用回应的机会。

    (我们注意到,自从本指南发布后,从资深黑客那里得到的唯一严重缺陷反馈,就是对预先道谢这一条。一些黑客觉得先谢了意味着事后就不用再感谢任何人的暗示。我们的建议是要么先说先谢了,然后事后再对回复者表示感谢,或者换种方式表达感激,譬如用谢谢你的关注谢谢你的关照。)

    问题解决后,加个简短的补充说明

    问题解决后,向所有帮助过你的人发个说明,让他们知道问题是怎样解决的,并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注,应该在那里贴一个说明比较恰当。

    最理想的方式是向最初提问的话题回复此消息,并在标题中包含已修正已解决或其它同等含义的明显标记。在人来人往的邮件列表里,一个看见讨论串问题 X问题 X - 已解决的潜在回复者就明白不用再浪费时间了(除非他个人觉得问题 X的有趣),因此可以利用此时间去解决其它问题。

    补充说明不必很长或是很深入;简单的一句你好,原来是网线出了问题!谢谢大家 – Bill比什么也不说要来的好。事实上,除非结论真的很有技术含量,否则简短可爱的小结比长篇大论更好。说明问题是怎样解决的,但大可不必将解决问题的过程复述一遍。

    对于有深度的问题,张贴调试记录的摘要是有帮助的。描述问题的最终状态,说明是什么解决了问题,在此之后才指明可以避免的盲点。避免盲点的部分应放在正确的解决方案和其它总结材料之后,而不要将此信息搞成侦探推理小说。列出那些帮助过你的名字,会让你交到更多朋友。

    除了有礼貌和有内涵以外,这种类型的补充也有助于他人在邮件列表/新闻群组/论坛中搜索到真正解决你问题的方案,让他们也从中受益。

    至少,这种补充有助于让每位参与协助的人因问题的解决而从中得到满足感。如果你自己不是技术专家或者黑客,那就相信我们,这种感觉对于那些你向他们求助的大师或者专家而言,是非常重要的。问题悬而未决会让人灰心;黑客们渴望看到问题被解决。好人有好报,满足他们的渴望,你会在下次提问时尝到甜头。

    思考一下怎样才能避免他人将来也遇到类似的问题,自问写一份文件或加个常见问题(FAQ)会不会有帮助。如果是的话就将它们发给维护者。

    在黑客中,这种良好的后继行动实际上比传统的礼节更为重要,也是你如何透过善待他人而赢得声誉的方式,这是非常有价值的资产。

    如何解读答案

    RTFM 和 STFW:如何知道你已完全搞砸了

    有一个古老而神圣的传统:如果你收到RTFM (Read The Fucking Manual)的回应,回答者认为你应该去读他妈的手册。当然,基本上他是对的,你应该去读一读。

    RTFM 有一个年轻的亲戚。如果你收到STFW(Search The Fucking Web)的回应,回答者认为你应该到他妈的网上搜索。那人多半也是对的,去搜索一下吧。(更温和一点的说法是 Google 是你的朋友!)

    在论坛,你也可能被要求去爬爬论坛的旧文。事实上,有人甚至可能热心地为你提供以前解决此问题的讨论串。但不要依赖这种关照,提问前应该先搜索一下旧文。

    通常,用这两句之一回答你的人会给你一份包含你需要内容的手册或者一个网址,而且他们打这些字的时候也正在读着。这些答复意味着回答者认为

    • 你需要的信息非常容易获得;

    • 你自己去搜索这些信息比灌给你,能让你学到更多。

    你不应该因此不爽;依照黑客的标准,他已经表示了对你一定程度的关注,而没有对你的要求视而不见。你应该对他祖母般的慈祥表示感谢。

    如果还是搞不懂

    如果你看不懂回应,别立刻要求对方解释。像你以前试着自己解决问题时那样(利用手册,FAQ,网络,身边的高手),先试着去搞懂他的回应。如果你真的需要对方解释,记得表现出你已经从中学到了点什么。

    比方说,如果我回答你:看来似乎是 zentry 卡住了;你应该先清除它。,然后,这是一个很糟的后续问题回应:zentry 是什么? 好的问法应该是这样:哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries,而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗?还是我看漏了什么?

    处理无礼的回应

    很多黑客圈子中看似无礼的行为并不是存心冒犯。相反,它是直接了当,一针见血式的交流风格,这种风格更注重解决问题,而不是使人感觉舒服而却模模糊糊。

    如果你觉得被冒犯了,试着平静地反应。如果有人真的做了出格的事,邮件列表、新闻群组或论坛中的前辈多半会招呼他。如果这没有发生而你却发火了,那么你发火对象的言语可能在黑客社区中看起来是正常的,而你将被视为有错的一方,这将伤害到你获取信息或帮助的机会。

    另一方面,你偶尔真的会碰到无礼和无聊的言行。与上述相反,对真正的冒犯者狠狠地打击,用犀利的语言将其驳得体无完肤都是可以接受的。然而,在行事之前一定要非常非常的有根据。纠正无礼的言论与开始一场毫无意义的口水战仅一线之隔,黑客们自己莽撞地越线的情况并不鲜见。如果你是新手或外人,避开这种莽撞的机会并不高。如果你想得到的是信息而不是消磨时光,这时最好不要把手放在键盘上以免冒险。

    (有些人断言很多黑客都有轻度的自闭症或亚斯伯格综合症,缺少用于润滑人类社会正常交往所需的神经。这既可能是真也可能是假的。如果你自己不是黑客,兴许你认为我们脑袋有问题还能帮助你应付我们的古怪行为。只管这么干好了,我们不在乎。我们喜欢我们现在这个样子,并且通常对病患标记都有站得住脚的怀疑)。

    Jeff Bigler 的观察总结和这个相关也值得一读 (tact filters)。

    在下一节,我们会谈到另一个问题,当你行为不当时所会受到的冒犯

    如何避免扮演失败者

    在黑客社区的论坛中有那么几次你可能会搞砸 —— 以本指南所描述到的或类似的方式。而你会在公开场合中被告知你是如何搞砸的,也许攻击的言语中还会带点夹七夹八的颜色。

    这种事发生以后,你能做的最糟糕的事莫过于哀嚎你的遭遇、宣称被口头攻击、要求道歉、高声尖叫、憋闷气、威胁诉诸法律、向其雇主报怨、忘了关马桶盖等等。相反地,你该这么做:

    熬过去,这很正常。事实上,它是有益健康且合理的。

    社区的标准不会自行维持,它们是通过参与者积极而公开地执行来维持的。不要哭嚎所有的批评都应该通过私下的邮件传送,它不是这样运作的。当有人评论你的一个说法有误或者提出不同看法时,坚持声称受到个人攻击也毫无益处,这些都是失败者的态度。

    也有其它的黑客论坛,受过高礼节要求的误导,禁止参与者张贴任何对别人帖子挑毛病的消息,并声称如果你不想帮助用户就闭嘴。 结果造成有想法的参与者纷纷离开,这么做只会使它们沦为毫无意义的唠叨与无用的技术论坛。

    夸张的讲法是:你要的是“友善”(以上述方式)还是有用?两个里面挑一个。

    记着:当黑客说你搞砸了,并且(无论多么刺耳)告诉你别再这样做时,他正在为关心你和他的社区而行动。对他而言,不理你并将你从他的生活中滤掉更简单。如果你无法做到感谢,至少要表现得有点尊严,别大声哀嚎,也别因为自己是个有戏剧性超级敏感的灵魂和自以为有资格的新来者,就指望别人像对待脆弱的洋娃娃那样对你。

    有时候,即使你没有搞砸(或者只是在他的想像中你搞砸了),有些人也会无缘无故地攻击你本人。在这种情况下,抱怨倒是真的会把问题搞砸。

    这些来找麻烦的人要么是毫无办法但自以为是专家的不中用家伙,要么就是测试你是否真会搞砸的心理专家。其它读者要么不理睬,要么用自己的方式对付他们。这些来找麻烦的人在给他们自己找麻烦,这点你不用操心。

    也别让自己卷入口水战,最好不要理睬大多数的口水战 -- 当然,这是在你检验它们只是口水战,并且未指出你有搞砸的地方,同时也没有巧妙地将问题真正的答案藏于其后(这也是有可能的)。

    不该问的问题

    以下是几个经典蠢问题,以及黑客没回答时心中所想的:

    问题:我能在哪找到 X 程序或 X 资源?

    问题:我怎样用 X 做 Y?

    问题:如何设定我的 shell 提示?

    问题:我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗?

    问题:我的程序/设定/SQL 语句没有用

    问题:我的 Windows 电脑有问题,你能帮我吗?

    问题:我的程序不会动了,我认为系统工具 X 有问题

    问题:我在安装 Linux(或者 X )时有问题,你能帮我吗?

    问题:我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢?


    问题:我能在哪找到 X 程序或 X 资源?

    回答:就在我找到它的地方啊,白痴 —— 搜索引擎的那一头。天哪!难道还有人不会用 Google 吗?

    问题:我怎样用 X 做 Y?

    回答:如果你想解决的是 Y ,提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知,也对 Y 要解决的问题糊涂,还被特定形势禁锢了思维。最好忽略这种人,等他们把问题搞清楚了再说。

    问题:如何设定我的 shell 提示??

    回答:如果你有足够的智慧提这个问题,你也该有足够的智慧去 RTFM,然后自己去找出来。

    问题:我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗?

    回答:试试看就知道了。如果你试过,你既知道了答案,就不用浪费我的时间了。

    问题:我的{程序/设定/SQL 语句}不工作

    回答:这不算是问题吧,我对要我问你二十个问题才找得出你真正问题的问题没兴趣 —— 我有更有意思的事要做呢。在看到这类问题的时候,我的反应通常不外如下三种

    • 你还有什么要补充的吗?

    • 真糟糕,希望你能搞定。

    • 这关我有什么屁事?

    问题:我的 Windows 电脑有问题,你能帮我吗?

    回答:能啊,扔掉微软的垃圾,换个像 Linux 或 BSD 的开源操作系统吧。

    注意:如果程序有官方版 Windows 或者与 Windows 有互动(如 Samba),你可以问与 Windows 相关的问题, 只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶, 因为 Windows 一般来说实在太烂,这种说法通常都是对的。

    问题:我的程序不会动了,我认为系统工具 X 有问题

    回答:你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的人,更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据,当你这样声称时,你必须有清楚而详尽的缺陷说明文件作后盾。

    问题:我在安装 Linux(或者 X )时有问题,你能帮我吗?

    回答:不能,我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使用群组者寻求实际的指导吧(你能在这儿找到使用者群组的清单)。

    注意:如果安装问题与某 Linux 的发行版有关,在它的邮件列表、论坛或本地使用者群组中提问也许是恰当的。此时,应描述问题的准确细节。在此之前,先用 Linux 和所有被怀疑的硬件作关键词仔细搜索。

    问题:我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢?

    回答:想要这样做,说明了你是个卑鄙小人;想找个黑客帮你,说明你是个白痴!

    好问题与蠢问题

    最后,我将透过举一些例子,来说明怎样聪明的提问;同一个问题的两种问法被放在一起,一种是愚蠢的,另一种才是明智的。

    蠢问题:

    我可以在哪儿找到关于 Foonly Flurbamatic 的资料?

    这种问法无非想得到 STFW 这样的回答。

    聪明问题:

    我用 Google 搜索过 "Foonly Flurbamatic 2600",但是没找到有用的结果。谁知道上哪儿去找对这种设备编程的资料?

    这个问题已经 STFW 过了,看起来他真的遇到了麻烦。

    蠢问题:

    我从 foo 项目找来的源码没法编译。它怎么这么烂?

    他觉得都是别人的错,这个傲慢自大的提问者。

    聪明问题:

    foo 项目代码在 Nulix 6.2 版下无法编译通过。我读过了 FAQ,但里面没有提到跟 Nulix 有关的问题。这是我编译过程的记录,我有什么做的不对的地方吗?

    提问者已经指明了环境,也读过了 FAQ,还列出了错误,并且他没有把问题的责任推到别人头上,他的问题值得被关注。

    蠢问题:

    我的主机板有问题了,谁来帮我?

    某黑客对这类问题的回答通常是:好的,还要帮你拍拍背和换尿布吗?,然后按下删除键。

    聪明问题:

    我在 S2464 主机板上试过了 X 、 Y 和 Z ,但没什么作用,我又试了 A 、 B 和 C 。请注意当我尝试 C 时的奇怪现象。显然 florbish 正在 grommicking,但结果出人意料。通常在 Athlon MP 主机板上引起 grommicking 的原因是什么?有谁知道接下来我该做些什么测试才能找出问题?

    这个家伙,从另一个角度来看,值得去回答他。他表现出了解决问题的能力,而不是坐等天上掉答案。

    在最后一个问题中,注意告诉我答案给我启示,指出我还应该做什么诊断工作之间微妙而又重要的区别。

    事实上,后一个问题源自于 2001 年 8 月在 Linux 内核邮件列表(lkml)上的一个真实的提问。我(Eric)就是那个提出问题的人。我在 Tyan S2464 主板上观察到了这种无法解释的锁定现象,列表成员们提供了解决这一问题的重要信息。

    通过我的提问方法,我给了别人可以咀嚼玩味的东西;我设法让人们很容易参与并且被吸引进来。我显示了自己具备和他们同等的能力,并邀请他们与我共同探讨。通过告诉他们我所走过的弯路,以避免他们再浪费时间,我也表明了对他们宝贵时间的尊重。

    事后,当我向每个人表示感谢,并且赞赏这次良好的讨论经历的时候, 一个 Linux 内核邮件列表的成员表示,他觉得我的问题得到解决并非由于我是这个列表中的名人,而是因为我用了正确的方式来提问。

    黑客从某种角度来说是拥有丰富知识但缺乏人情味的家伙;我相信他是对的,如果我像个乞讨者那样提问,不论我是谁,一定会惹恼某些人或者被他们忽视。他建议我记下这件事,这直接导致了本指南的出现。

    如果得不到回答

    如果仍得不到回答,请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视,虽然不可否认这种差别很难区分。

    总的来说,简单的重复张贴问题是个很糟的点子。这将被视为无意义的喧闹。有点耐心,知道你问题答案的人可能生活在不同的时区,可能正在睡觉,也有可能你的问题一开始就没有组织好。

    你可以通过其他渠道获得帮助,这些渠道通常更适合初学者的需要。

    有许多网上的以及本地的使用者群组,由热情的软件爱好者(即使他们可能从没亲自写过任何软件)组成。通常人们组建这样的团体来互相帮助并帮助新手。

    另外,你可以向很多商业公司寻求帮助,不论公司大还是小。别为要付费才能获得帮助而感到沮丧!毕竟,假使你的汽车发动机汽缸密封圈爆掉了 —— 完全可能如此 —— 你还得把它送到修车铺,并且为维修付费。就算软件没花费你一分钱,你也不能强求技术支持总是免费的。

    对像是 Linux 这种大众化的软件,每个开发者至少会对应到上万名使用者。根本不可能由一个人来处理来自上万名使用者的求助电话。要知道,即使你要为这些协助付费,和你所购买的同类软件相比,你所付出的也是微不足道的(通常封闭源代码软件的技术支持费用比开源软件的要高得多,且内容也没那么丰富)。

    如何更好地回答问题

    态度和善一点。问题带来的压力常使人显得无礼或愚蠢,其实并不是这样。

    对初犯者私下回复。对那些坦诚犯错之人没有必要当众羞辱,一个真正的新手也许连怎么搜索或在哪找常见问题都不知道。

    如果你不确定,一定要说出来!一个听起来权威的错误回复比没有还要糟,别因为听起来像个专家很好玩,就给别人乱指路。要谦虚和诚实,给提问者与同行都树个好榜样。

    如果帮不了忙,也别妨碍他。不要在实际步骤上开玩笑,那样也许会毁了使用者的设置 —— 有些可怜的呆瓜会把它当成真的指令。

    试探性的反问以引出更多的细节。如果你做得好,提问者可以学到点东西 —— 你也可以。试试将蠢问题转变成好问题,别忘了我们都曾是新手。

    尽管对那些懒虫抱怨一声 RTFM 是正当的,能指出文件的位置(即使只是建议个 Google 搜索关键词)会更好。

    如果你决定回答,就请给出好的答案。当别人正在用错误的工具或方法时别建议笨拙的权宜之计(wordaround),应推荐更好的工具,重新界定问题。

    正面的回答问题!如果这个提问者已经很深入的研究而且也表明已经试过 X 、 Y 、 Z 、 A 、 B 、 C 但没得到结果,回答 试试看 A 或是 B 或者 试试 X 、 Y 、 Z 、 A 、 B 、 C 并附上一个链接一点用都没有。

    帮助你的社区从问题中学习。当回复一个好问题时,问问自己如何修改相关文件或常见问题文件以免再次解答同样的问题?,接着再向文件维护者发一份补丁。

    如果你是在研究一番后才做出的回答,展现你的技巧而不是直接端出结果。毕竟授人以鱼不如授人以渔

    相关资源

    如果你需要个人电脑、Unix 系统和网络如何运作的基础知识,参阅 Unix 系统和网络基本原理。

    当你发布软件或补丁时,试着按软件发布实践操作。

    展开全文
  • 【答学员问】如何提问问题

    千次阅读 2019-11-04 21:34:04
    文章目录如何向别人提问提问前必须做什么?怎么提问?增强自己的逆商人与人之间的差别只在于是否能灵活应用工具总结: 如何向别人提问 提问前必须做什么? 首先明确自己出现这个问题之前做了哪些操作,把做过的操作...

    如何向别人提问

    提问前必须做什么?

    1. 首先明确自己出现这个问题之前做了哪些操作,把做过的操作记录下来
    2. 排除基本故障(防火墙、Selinux、权限等)
    3. 查看相关报错信息,出现error关键词或者其他错误信息关键词,找出报错信息的核心,复制进百度先大体看下是啥问题。
    4. 查看相关的日志(服务日志,系统日志等),查看相关错误,来佐证第2条中自己整理出来的核心关键词是否准确
    5. 通过百度检索发现类似问题,尝试在自己机器上解决,若解决无效果,回滚,继续检索另外的答案
    6. 通过官方文档核实相关问题
    7. 如果研究了很久依旧没有解决,可以把问题的前因后果及曾经的解决方案写下来,询问相关人员。

    怎么提问?

    前因(环境)
    后果(报错)
    尝试了哪些处理
    将过程写到Word或写到博客上,方便别人查看
    问问题禁忌:

    1. 别说废话,不要动不动在群里喊有没有大神帮我看看吧,不好意思没人愿意搭理你。
    2. 不要@管理员,有事说事,只要不是发广告,你问问题不会有人踢走你,别动不动就@
    3. 别上来就说一句:有人会docker吗,然后没下文了,没人说自己会
    4. 问题发了之后,多盯着点你发的群,别你发了,别人给你回了,你第二天才想起来给个回复。
    5. 最后记得感谢曾经帮你回答过问题的人,哪怕没有给出帮助也要记得答谢。

    增强自己的逆商

    什么叫逆商? 就是遇到问题(挫折,困难)时候的反应方式。
    之前有学员问我, 在公司里遇到技术问题,有经验的大牛是怎么处理问题的?
    我的回答是: 记录下问题,记录下问题产生的原因,百度或者google找到解决方案,进行试验,发现不行,重新百度或者谷歌找到解决方案,发现还不行,继续查找问题,排除刚才已经试过的方案,直到问题解决。
    解决后,写下解决思路,并思考出现问题的原因,总结笔记,下次遇到类似的问题可以直接翻看自己的笔记。
    一个有工作经验的人之所以比你定位更准确,是因为他有自己的知识体系,以及拥有自己的错误库,这个错误库就是他能快速找到问题原因的根本。 如果现在遇到的问题在错误库中,他可以直接调用解决,如果不在错误库中,说明可以直接排除百度出来的错误库中的内容,缩小解决问题的范围。
    而作为一个还没有工作经验的你来说,首先先找到问题的答案,这就需要你花费更多的时间去百度和尝试。

    人与人之间的差别只在于是否能灵活应用工具

    动物跟人的区别是是否能够使用工具,而人与人的差别是是否能灵活应用工具。 哪些是你工作之后的工具?
    百度,谷歌是工具
    你身边的同事是工具
    你的朋友圈的人脉是工具
    这里的工具并非贬义词,能够把当前所拥有的资源转化为解决当前问题的所需要的能力,你就成功了。

    总结:

    遇到问题要学会使用工具去解决,而不要停留在逃避,生气的层面,你能做的就是拿起工具,去解决问题,提高自己的逆商,磨炼自己的耐心,踏踏实实的去解决一个又一个问题,这种能力不单单体现在工作上,还体现在你人生中的每一个抉择上。

    展开全文
  • 通过我国环境监管体制、环境监管方式、环境监管法律体系的介绍,阐述我国环境监管的现状,研究环境监管中存在的问题,分析造成项目审批忽视环保、"三同时"监管存在漏洞、行政管理效率低下、执法手段软弱无力、监管力量...
  • 为了解决路网环境中传统的组最近邻查询无法支持用户不确定搜索的问题,在组最近邻查询的基础上引入了模糊因子来描述用户查询的不确定性,并提出了四种不同的算法。其中朴素的全局搜索算法利用了Dijkstra算法的特性...
  • 节能环保是煤炭企业可持续发展的必然选择,对于国家能源和环境安全、经济社会高质量发展和企业软实力提升等具有重要意义。通过对煤炭企业节能环保工作现状的概述性分析,指出其存在的主要问题,并提出相关建议。
  • 在对近年来小煤矿关闭后环境和安全问题调查的基础上,对小煤矿关闭后引发的水患和地质灾害问题、生态和社会人文环境问题进行了分析研究。提出了落实小煤矿关闭安全与环境治理的主体责任;建立小煤矿关闭后安全环境保护...
  • [摘要]在全球信息化大势所驱...本文从我国电子商务技术发展的环境,存在的问题,个人对部分问题的分析及提出的解决方法三个方面,探讨分析了我国电子商务发展的现状、存在问题和个人对部分问题的分析及提出的解决方法。
  • 分析了小煤矿关闭后涉及的生态环境、水污染、瓦斯气体泄漏等环保问题,提出了新形势下解决煤矿关闭涉及环保问题的治理技术及管理途径,包括制订煤矿关闭长期计划,保管好技术资料,加强对关闭煤矿区域环境的监测与治理等...
  • 在煤矿开采中,矿山环境地质问题...在此,结合实例分析了煤矿地质环境,对煤矿矿山地质环境保护和治理区域加以划分,并就不同区域提出了针对性的治理措施,通过环境地质问题的综合治理,能够取得显著的经济效益与社会效益。
  • 饮用水安全问题关系到广大人民群众的健康、生命安全和社会的和谐稳定。开展饮用水源地基础环境调查与评估,研究提出江苏省主要饮用水...重点阐述了江苏省饮用水源地存在的环境问题,针对问题提出相应的管理对策和建议。
  • 结合公路环境评价和水土保持方案设计的工作实践,论述了公路建设中环境保护的必要性,分析了公路工程各建设阶段的环境问题和应采取的环保对策,提出了加强公路建设环境管理的几点建议。
  • 从近年来的建设项目竣工环保验收情况来看,尽管逐年有所提高,但新开工的项目验收率仍不容乐观,同时遗留的历史...本文对建设项目环境保护设施验收管理的现状、存在的问题进行了阐述,并就如何进一步提高验收率提出了建议。
  • 日益突出的环境问题对经济发展的阻碍作用已受到社会的广泛关注,...对我国实施环境会计的必要性、环境会计核算的特殊性,以及我国目前实施环境会计存在的问题等进行了简要介绍,并对我国进一步开展环境会计提出了建议。
  • 第一点:思维逻辑的要点,首先提出问题要环环相扣,也就是讨论问题时的每个提问应该和上一个提问有关联,更深入,而不能跳跃,跳跃会导致讨论无法深入。 第二点:提取关键字,快速做出分析(批判性的),如果没那么...
  • 基于随着经济的快速发展,环境问题也逐渐被提上日程,越来越多的国家和政府开始重视环境问题,由此衍生出了一个新的课题,即关于环境会计的问题。重点对环境会计发展存在的问题及成因进行了深入而系统的分析,最终提出...
  • 针对目前我国煤炭开采对地质环境破坏的现状,分析和评述了发生在山西煤矿区的主要环境地质问题,指出了煤矿开采对地质环境破坏的主要表现形式为地表变形、水资源受损、水环境变异、生态环境衰退和地貌景观改变,并根据...
  • 为了解决资源型城市阜新市的矿山环境污染问题,采用测试、化验...并提出了矿产资源型城市主要矿山环境问题的治理方法。研究成果对以矿山为主要工业的资源型城市的矿山环境污染问题的治理具有一定的参考价值和指导意义。
  • 分别从耕地损失和居民搬迁、景观和空间结构变化、环境污染等方面对淮南潘谢矿区的环境问题及其治理现状进行了剖析,指出了环境管理中存在对未稳定沉陷区的治理重视不足、居民搬迁安置工作缺乏长远考虑、污染控制要求...
  • 概要列出了阜新市因煤炭开采而产生的一系列的矿山环境问题,并针对这些具体问题,提出了一系列的治理措施。最后提出具体建议,改善我国的矿山环境,实现资源与环境的协调发展。
  • 新安县矿业开发在满足经济发展的同时也产生了许多矿山地质环境问题,主要有矿山开发引发的地质灾害、地形地貌景观破坏、土地资源占用和破坏、固体废物堆积、矿区水均衡破坏等问题。对矿山地质环境进行了现状分区,划分...
  • 如何更聪明的提问问题

    千次阅读 2018-01-11 00:00:00
    【回复“1024”,送你一个特别推送】最近看了一篇文章,深有感触,决定写一下自己的感受,因为我也经常遇到这样的困扰,那就是很多人加我个人微信号,给我发邮件等提问问题。但是提问人问问题的水平真的是太差劲了,...
  • 山东省环境问题分析及对策研究,周生厚,宋宪强,本文分析了山东省环境问题的现状及形成原因,在此基础上提出了解决环境问题的对策。
  • 通过对消费问题的理论透视,提出人类要摆脱环境问题就必须首先变革传统消费理念,消除和解脱不良消费模式。所谓消费问题乃是人类的消费行为存在问题,其最大特征就是消费大大超过了人类自身的实际需要,诸如高消费、...
  • 本文以煤炭资源开发各环节活动及开采形式为基础,分析和探讨了煤矿建设和生产对矿山地质环境的影响,探讨了问题类型及特征,并给出了不同开采形式对矿山地质环境影响的关系,并提出了矿山地质环境问题防治工作进一步开展...
  • 目前,动力环境监控系统已经在国内得到了广泛的应用。但在建设过程仍存在着大量的问题,制约甚至阻碍了监控系统的正常发展。本文提出了存在的问题,分析了产生的原因以及解决的方法。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 518,208
精华内容 207,283
关键字:

关于环境的提出的问题