看似很老套的论调，但是我写还是写出新的东西出来。
标签： 管理
用户体验能改变企业级IT吗
这是一篇转译自HBR的文章，作者是来自FrogDesign和GE的两位Innovator，他们的立足点促使我转译了这篇文章，在更为广阔的消费市场及用户体验方面，两者都获得了相当的成功，换句话说就是在多数人的世界里，他们的体验是更为敏锐和“高效”的，那么对于企业级的IT而言，对于需要强有力支持的员工，什么样的IT跟上了Evolution，也是相当重要的。所以我们应当看看这两位实际上是Designer的观点如何。
自动化管理生活的十项技巧
这篇文章来自于LifeHacker最近的一篇博客（WhitsonGordon），适逢年假期间有点乱，正好可以借鉴一下这些技巧。
每个人都希望成为一名魔法师，可以随心所欲的掌控生活，但这显然是不靠谱的。靠谱的是通过一些手段，使用一些技巧来实现某种程度的自动化管理，是我们摆脱这些恼人的生活杂事，让家务事可以自行处理，自动缴纳水电煤（not 天朝）。。。
下面列出的就是你现在就可以动手的十件事：
腐蚀设计和创新的指标
最近一段时间，一直以来盛行的各种企业考核指标，第一次被公众大规模地批判与抵制，这是一种信号，一次产业变革的信号。
现在的创新企业，最无惧的，也正是这些指标。对于经济学家而言，似乎没有公式没有数学理论支撑的企业管理以及战略分析等等，都是无法接受的，所以企业被分析，分拆、量化，在各种数据中被拼凑出了各种考核的要素，然后各大公司就开始按照这些指标的要求，对员工、产品、部门进行了各式各样千奇百怪的考核，甚者，还有综合了心理学的分析理论，来评估一个人的贡献和潜在风险。
而这些，就是毒瘤，一个被很多管理人员视而不见的毒瘤，他们愿意花钱雇佣一群专家来做各种评估，愿意浪费宝贵的研发时间来完成阶段任务验收，却不愿意深入考虑消费者的真实需求，员工的研究环境和公司的长远使命这些无法量化和考核的东西。
柯达，销售公司之殇
在家的时候，翻出了小时候的照片，看照片之余，就联想到了柯达，一个已经倒下的巨头，我觉得可以感觉到，当柯达剧院更名的时候，有一个时代的结束。
柯达的倒下可以说是必然的，很多类似的公司都倒下了，众所周知渡过这一难关的，有IBM，也成就了郭士纳。然而我觉得背后的那只推手还是中国，如果大家都知道04年的时候柯达还在中国投下了世界最大的一次性相机生产基地。或者可以体会到大街小巷满山遍野处红黄相间的Kodak标志。
关于“近亲创新”的一些事
这是最早在HBR Blog 上的一篇文章，讲的是很匪夷所思的话题，近亲创新的问题。
在这篇文章里，首先从Economist引述了一个故事，北美将建立的第一个大象精子库，有一头大象在过去的一个世纪中被引为美国很多小牛的父亲，之所以这么做，专家的解释是为了防止后代出现近亲的现象。
专家认为，近亲的现象反而代表了一个实际问题，携带了导致物种体格衰弱的隐性基因非常容易配对，而适应能力拖累了。通过一个“冷冻小飞”的项目，试图通过引入新的基因的方式，来最大程度地降低近亲的危害。
而实际上，很多的以创新为己任的领导人，都受制于亲近创新，在很多公司中，这几乎让人无法忍受。
一般发生近亲创新的情况是，公司的重要变革和创新任务交给由和公司生命几乎纠缠在一起的一些人来完成，更糟糕的情况是就是这些创新还仅仅发生在独立的部门，环节和产品线里。
在进行创新的改革之路的时候，最重要的部分在于，真正具备突破性的创新来自于不同学科领域交叉的十字路口。英国经济学家约翰·朱克斯在20世纪50年代的研究表明在20世纪所发生的重大发明，至少有46个人发生在“错误的地方” – 在非常小的企业，在大公司的“局外人”，或在大公司，却在错误的行当里。
一下是三个有效的，可以避免近亲创新的办法：
·强制促进内部交流，大公司的分散度令人惊讶，往往可以汇集来自不同功能，不同地域，不同层次，不同业务单位的代表，可以导致突破思维定势的创新想法。例如IBM 的创新JAM，就是汇集了数千名员工，专家，外部人员，甚至是家人的成果。而你并不需要消耗掉你的差旅费用来应对不断增长的在线协同工具。
·把局外人来进来，非常惊奇的是我一直看到不断有新进入市场的公司犯下任何接受了一定培训的公司都会避免的错误，不过有选择地引入局外人可以从一定程度上改变既有的游戏规则，即使从内部进行挖掘也未尝不可，宝洁就是这么做的，通过挖掘内部的青年才俊来探索新的商务模式。
·把消费者或其他利益相关者拉进来，把消费者带入一个创新的活动很明显具有极大的危险性，消费者很可能会制约公司的理念的发展，但埃里克·希佩尔的研究得出结论显示，在许多行业中客户以更快的速度作出超越公司本身的创新产品，考虑采用修改后大卖的自行车的人所使用的框架结构，或者甚至发明厨师的食谱。尽管和客户合作听起来已经很老土，但是毫无疑问的是这会带来巨大的回报。
所以不用为沉沦在近亲创新中而苦恼，而是积极地跨越障碍获取进步。
我的看法：作者所指的近亲创新，通俗地将来就是我们中国的古语：近墨者黑，近朱者赤，久而不闻鲍肆之臭。对于公司而言，就是创新部门的创新者，会有着非常类似接近的创新思路和风格，因为围绕着某一个成功产品开展的，都是辅助围绕的工作，所以招募进来的人，都是符合当前热门产品的创新需求的人选，而不是持续创新的人选，时间长了 ，就如近亲结婚一样，相同类型的人所作出的产品会明显地暴露出他们共同的短板，这也是谷歌给工程师们留下20%自由时间的原因，也是Apple的主要力量在设计是手中而不是硬件工程师手中，单看Apple二度崛起的案例，也就是说的这个案例。
推和拉
PMPOK上说到，信息的交换可以分为推式和拉式。
这一点我现在有比较多的探究，因为这是很关键的一个问题，这么多数据堆砌起来的时候，选择主动接受和被动接受将对处理信息产生很大的影响。
就目前而言，在工作环境中，更多地倾向于推式，比如弹窗和PUSH MAIL，在工具类小插件和应用中，使用推式的产品很受欢迎，因为对于工作人员而言时间很宝贵，所以信息最好是主动地跳出来比较好。
在生活中，更多地是拉式获取信息，比如在用社交站点的时候，尽管大部分的站点都有及时信息滚动和提示，但是很多人都会主动地去刷新以获得信息。
对比之下，这两种方式的差异还是比较大的，最突出的一点就在于对资源的损耗上。对于主动的推式信息而言，将会产生大量的资源消耗，而且信息往往也是来不及做处理就被推送到用户的面前。拉式信息则没有大幅地资源消耗，而且往往可以对信息进行一定的处理，却降低了有效性。
随着语义搜索的实际应用，一直以来处于低位的拉式信息由一点抬头的迹象，很多人觉得牺牲一定的时间来换取结果的准确和有效性是值得的，我们习惯地以为准确的结果相当重要，这一点对于得到答案为目的的情景里是母庸置疑的，但是我们也需要考虑一下不利的一面。
今天距离上一次开动写本文的时候已经过去了三天，期间我被动推送了一条点评网的促销信息，并且使用了该优惠，这是一条有用的推式信息，然后我再淘宝网上帮人买东西的时候，由于看到通知，主动地拉取了优惠券的使用方法这也是一条有效的拉式信息。在这里比较明显地是人为的设计对于用户信息导向的作用。正如乔布斯广为流传的一句话说的是，用户很多时候并不知道他们需要的是什么，所以我们要设计好给他们，这是一种先被动后主动的价值观传递的过程。从苹果公司的例子中可以看到，按照一定的目的去规划，使用推和拉的方式，可以达成目的。
于此同时有一个例子是中远集（远洋运输），上了船舶管理系统之后，中远的总裁在办公室里可以随时看到中远旗下每一艘船只的情况，这是一个推式系统，但是所有人都知道，中远的总裁不可能也不需要去查看每一艘船，他会挑选其中的一些进行查看，这是来自用户自身的主动式拉取，在这一过程中消息的推送就不怎么起作用了。
所以从严格上来说，并没有什么好坏之分，即便是在某些情况下适合某种形式的消息推送，也会因为环境因素等的变化而变化，比如一个项目在一开始的时候是以推送为主，随着项目进入攻坚阶段，就会转到拉取，这一变化是由用户在自己都不知情的情况下发生的。通过关系式的监察和过滤机制，可以总结出一些特定的环境和适用的案例情况，从而应用某种框定完善的消息机制来给用户提供最大的便利。
更安全地解决访问控制管理员权限
在目前现有的访问控制权限列表里，对于管理员组的权限已经给的比较大了，并且在启用系统自己的管理员权限之后，用户几乎可以访问除特定的系统文件除外的所有内容.
对于系统文件，我不太赞同向右键添加“管理员控制”的方法，毕竟点击右键几乎是所有人都会操作一次的。我个人还是推荐通过访问指定目录打开后再关闭的访问进行访问，即按需给予权限。
我们知道，有些应用程序会在Templates里下载包，有的人希望把这些包抓出来，这就需要你紧紧地盯着Templates文件夹，你只需要把路径敲进去就可以了。
写好了这个批处理文件，你可以自己改成其他的你知道的名字（如：XX的记事本清理），这样更加安全。拷贝如下代码，新建文本文档存入，修改文件类型为.bat。该文档以ANSI编码。
@echo ╔======================╗ @echo made by flanker @echo ╚======================╝ @echo 请输入目标路径（建议复制粘贴）并回车： @set/p 路径名= >nul takeown /f "%路径名%" /r /d y icacls "%路径名%" /grant administrators:F /t msg * 操作已完成,继续将打开目标 @pause @explorer.exe %路径名%
运行如图：
运维咆哮，WIN和Linux，你们如何手挽手
作为一个运维，接触的大部分服务器是以Linux居多，WIN随后，UNIX也占据一定的份额。对于一个运维来说，稳定、安全、高效，这是对于服务器的三大要求，几乎和机器人的三大法则一样，深深地扎根在运维和系统的根里。
先看第一个版本的咆哮，为什么对Linux怒吼：
一句新的格言是，对于有着正常生活的人来说，幸好还有Windows。
实不相瞒，这其实是一篇不停地大声抱怨Linux的文章。但是现在我生气得很，沮丧得很。众所周知，Linux人员打心底里就瞧不起没有夜以继日地琢磨Linux发行版细枝末节的人，但我有句话要说：我可不像你们这样Linux人有的是大把时间来钻研技术。
我受够了Linux
我受够了。我受够了所有拼凑起来的各系统部分必须版本刚刚好，必须有刚刚好的依赖关系，必须以刚刚好的方式来编译，必须选择刚刚好的时机，还必须数量刚刚好的的人员在刚刚好的时间步调一致。
我受够了所有不同的软件包管理器。一些代码使用某一个软件包管理器来分发，另一些代码则使用别的软件包管理器来分发。受够了只要按照资料不充分的HOWTO文件，在终端窗口中机械地输入一行行代码，可以将模块下载到Ubuntu上，却根本无法下载到CentOS或Fedora上，就因为没有按刚刚好的顺序来指定代码存储库。