Daily Archives: 2016年6月2日

“System.Data.Entity.Internal.AppConfig"的类型初始值设定项引发异常。

必须写在

之后 。 from:http://www.cnblogs.com/A2008A/archive/2012/08/10/2631443.html

如何用开源经历为你的简历增加光彩

在这篇文章中，我将会分享我的方法，让大家利用开源贡献在技术领域的求职中脱颖而出，成为强有力的候选者。 凡事预则立，不预则废。在你即将进入一个新的领域或者正准备熬夜修订你的简历之前，清楚地定义你正在寻找的工作的特征是值得的。你的简历是一部有说服力的作品，因此你必须了解你的观众，从而让它发挥出所有的潜力。看你简历的可能是任何需要你的技能并且能在预算之内聘用你的人。当编辑简历的时候，读一读你的简历上的内容，同时想象一下，以他们的角度怎么看待这份简历。你看起来像是一个“你”将会聘用的候选人吗？ 我个人认为，对于目标职位的理想候选人所表现出来的关键特征，列出一张清单是很有帮助的。我结合了个人经验、阅读工作招聘信息、询问相同角色的同事等方面来收集这个清单。LinkedIn 和各种会议是寻求一些乐意提供这种建议的人的很好的地方。一些人喜欢谈论他们自己，那么通过邀请他们讲述他们自己的一些故事可以帮助你来拓展你的知识面，这样大家都会感觉很好。当你和其他人谈论他们的职业路线时，你不仅将会明白怎样去得到你想要从事的工作，而且还能知道你应该避免那些容易让你失去工作机会的特征或行为。 例如，对于一个不太资深的工作位置来说，关键特征列表可能如下所示： 技术方面： 拥有 CI (持续集成) 方面的经验，特别是 Jenkins 深厚的脚本编写背景，如 Python 和 Ruby 精通 Eclipse IDE 基本的 Git 和 Bash 知识 个人而言： 自我驱动的学习者 良好的交流和文档技巧 在团队开发方面富有经验（团队成员） 精通事件跟踪的工作流 尽管去申请职位 记住，你没有必要为了得到一份工作而去满足上面的工作描述列表中列出的每个标准。 工作细节（JD）描述了这个角色，让你一开始就知道你即将签约并为之工作几年的公司的全部信息，并且这份工作并不会让你觉得有什么挑战性，或者要求你去拓展你的技能。如果你对你无法满足清单上的技能列表而感到紧张，那么检查一下自己是否有来自其他方面的经历并能与之媲美的技能。例如，即使有些人从来没有使用过 Jenkins[1]，那他也可能从之前使用过Buildbot[2] 或者travis CI[3] 的项目经验中明白持续集成测试的原则。 如果你正在申请一家大型公司，他们可能拥有一个专门的部门和一套完整的筛选过程来确保他们不会聘用任何不能胜任职位的候选人。也就是说，在你求职的过程中，你所能做的只是提交申请，而决定是否拒绝你是公司管理层的工作。不要过早地将工作拒之门外。 现在你已经知道了你的任务是什么，并且还知道你将需要让面试官印象深刻的技巧。下一步要做的取决于你已有的经验。 制造已经存在的事物之间的关联 列出一张你过去几年曾经参与过的所有项目。下面是一条快速得到这张清单的方法，跳转到你的 Github profile 中的Repositories标签页，并且过滤掉 fork 过来的项目。除此之外，检查下你的清单上是否有曾经处于领导地位的Organizations[4]。如果你已经有了一份简历，那么请确保你已经将你所有的经历都列在了上面。 考虑下任何一个你曾经作为一个潜在的领导经历并拥有过特权的 IRC 频道。检查下你的 Meetup 和Eventbrite 账号，并将你曾经组织过或者作为志愿者参与过的活动添加到你的清单上。浏览你前几年的日程并且标注所有志愿服务，或者有作为导师的经历，又或者参与过的公共演讲。 现在进入了比较艰难的环节了，将清单上列出的必备技能与个人经历列表上的内容一一对照，我喜欢给该工作所需要的每个特征用一个字母或者数字作为标记，然后在每一段你经历或参与过并表现出了某一特征的地方标记相同的符号。当你不太确定的时候，那就毫不犹豫地标记上它，尽管这样做更像是在吹嘘，但也好过显示出你的无能。 在我们写简历的时候常常被这样的情况所困扰，就是我们不愿冒着过分吹嘘自己的技能的风险。通常应该这样去想，“那些组织了聚会的人会表现出了更好的领导才能和计划技巧吗？”，而不是“当我组织了这个聚会的时候我是否展示出了这些技巧？”。 如果你已经充分了解了你在过去的一两年里的业余时间都是怎么度过的，而且你写了很多代码，那么你可能现在正面临着一个令人奇怪的问题，你已经拥有了太多的经验以至于一张纸的简历已经无法容纳下这些经验了。那么，如果那些列在你的清单上的经验，但无法证明你尝试去表现的任何技能的话，那么请扔掉它们吧。如果这份已经被缩短的简历清单上的内容仍然超过一张单页纸的容量的话，那么将你的经验按照一定的优先级排序，例如根据与所需技术的相关经历或丰富经验。 在这一方面，显而易见，如果你想要磨练一个独特的技能，那么你就需要一个不错的经历。考虑使用一个类似 OpenHatch[5] 的问题聚合器，并用它来寻找一个通过使用你从没使用过的工具和技术来锻炼你的技能的开源项目。 让你的简历更加漂亮 一份简历是否美观取决于它的简洁度、清晰度和布局。每一段经历都应该通过足够的信息来展示给读者，并让他们立刻明白为什么你要将它包含进去，而且恰到好处。每种类型的信息都应该使用一致的文档格式来表示，一份含有斜体格式的日期或者右对齐的或者与整体风格不协调的部分绝对会让人分心。 使用工具来给你的简历排版会使之前设定的目标更加容易实现。我喜欢使用 LaTeX[6]，因为它的宏系统能够使可视化一致性变得更加容易，并且大量的面试官都能一眼就认出它。你的工具的选择可能是LibreOffice[7] 或者 HTML，这取决于你的技能和你希望怎样去发布你的简历。 记住一点，一份以电子方式提交的简历可以通过关键字被浏览到。因此，当你需要描述你的工作经历的时候使用和工作招聘告示一样的英文缩写对你的求职会有很大的帮助。为了让你的简历更加容易被面试官看到，首先就要放上最重要的信息。 程序员通常难以在为文档排版时量化平衡和布局。我最喜欢的修改和评估我的文档中的空格是否处于正确位置的技术，就是全屏显示我的 PDF 或者打印出来，然后在镜子里面查看它。如果你正在使用 LibreOffice Writer，保存一份你的简历的副本，然后将你的简历中的字体换成一种你看不懂的语言。这两种技术都强制将你从阅读的内容中脱离出来，让你以一种新的方式查看文档的整体布局。他们把你从一个“那句话措辞不当！”这样的批评转到了注意如“在这行上只有一个字，看起来挺逗”之类的事情。 最后，再次检查你的简历是否在它将要的展示的多媒体上看起来完全正确。如果你以网页的形式发布它，那么在不同屏幕大小的浏览器中测试它的效果。如果它是一份 PDF 文档，那么在你的手机或者你的朋友的电脑上打开它，并确保它所需要的字体都是可用的。 接下来的步骤 最后，不要让你辛苦做出来的简历内容浪费了，将它完整的复制到你的 LinkedIn 帐号上（完全使用招聘公告中的流行词），然后毫无疑问招聘人员就会找到你了。尽管他们描述的工作内容并不是恰好适合你，但是你可以利用他们的时间和兴趣来得到关于你的简历中有哪些地方好与不好的反馈信息。 作者：edunham[8] 译者：pengkai[9] 校对：mudongliang[10]，wxy[11] 本文由 LCTT[12] 原创编译，Linux中国[13] 荣誉推出 [1]: https://jenkins-ci.org/ [2]: http://buildbot.net/ [3]: https://travis-ci.org/ […]

17 年编程生涯的三大经验总结

今年将迎来我编程的第十七个年头。我的编程之旅始于九十年代末，上大学的时候，主要涉足基于表格的网页设计，传统的ASP，和Microsoft Access数据库。原来只是当作业余爱好的编程现在已经成为了我的事业和激情。我一生一半的时间都在学习、蹒跚、成功、失败，并且经常情不自禁地为代码 美丽和复杂的天性而折腰。 我在代码上淫浸了足够长的时间，因此看到了很多语言和平台的兴盛和消亡，看到了很多模式被普及，被苛责，然后再次被推广。在某些时候，我常常分不清这是大势所趋还是明日黄花。 编程的流行趋势是短暂的，但我坚守的规则，往往在生活中的其他地方也能发挥作用。事实上，生活就像代码（我已经买了这个域名来证明这一点！）。以下是我总结的3个伟大的经验教训，历经一次又一次编程和生活的大浪淘沙。 1.可商榷的决定往往是一种权衡。 伟大的辩论总是发生在开发社区中。无论它是最近关于TDD作为web开发的一种可行方法的辩论，还是什么水平的开发人员应该使用ORM（或 micro-ORMs）。无论是.NET MVC应该优于WebForms还是以JavaScript为中心的app应该比基于页面的app更受青睐，对我来说，答案都一样：看你权衡之后的取舍？ 在任何比较两种流行方法的辩论中，我们总是会从自己的立场出发，两利相权取其重，两害相权取其轻。在我的职业生涯早期，我曾执着于追求所谓的正确答 案。感觉过程是线性的：摆脱做事的老办法，转而投向新的并且更好的方法的怀抱。曾经有一段时间我深信，编写自己的SQL查询是一种过时的练习，并且 ORMs是最后赢家。 但是，我了解到，更好的办法应该由内容决定的。例如，今天完全成熟的ORMs在隔离映射相关数据网格到对象的冗长管道提供了伟大服务，但隔离也使得某种非标准查询变得困难并且有潜在的效率低下问题。n+1 select problem就是经典的在少写代码和写更多高效代码之间做权衡。我使用ORM的程度完全受我期待应用程序使用的数据量，我所受到的潜在的时间限制，app长期可扩展性需求这三者的影响。（顺便说一句，我目前是micro-ORMs，比如说Dapper的忠实粉丝，它能让我编写我自己的SQL和一些精巧的对象-关系映射）。 我已经将这个经验应用到了我生活的其他方面。我是应该买一套公寓还是长租房子？我是应该启动自己的生意还是工作于已经成立的公司？没有绝对正确的选择。当你权衡利弊了之后，你便可以更好地应对生活中的各种难题。 2.清晰并不总和简洁相关。 和大多数工程师一样，我对持续重构一直到代码尽可能地少和简洁的机会垂涎三尺。如果可以选择更少又更简洁的代码来完成同样的任务，那么我为什么要选 择要个更多代码的方案呢？通常情况下，更简洁的语言会导致更好的交流。画蛇添足只会阻碍核心信息的提取。但是，最终的目标不应该是简洁——而应该是可交 流。于我而言，下面这段直截了当的代码，在它更长的时候…… ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 if (HasFarm() && HasBoat()) {   Broadcast("You are wealthy!"); } else if (HasFarm() && !HasBoat()) {   Broadcast("You are OK!"); } else if (!HasFarm() && HasBoat()) {   Broadcast("You are OK!"); } else if (!HasFarm() && !HasBoat()) {   Broadcast("You are poor!"); } ……反而比这个简洁版本更明确。 ? 1 2 3 (HasFarm() && HasBoat()) ? Broadcast("You are wealthy!") :  (HasFarm() || HasBoat()) ? Broadcast("You are OK!") :  Broadcast("You are poor!"); 虽然这是一个品味问题（有些人可能会觉得后者看上去更加一目了然），但是我在这里要表述的观点是，有时候解释的最伟大方法并不是简化。这个经验也适 用于日常生活，我花了大量时间来思考怎么样才能更好地传达消息以便于对方接收——有时更详细的讲解并非没有价值，而是更明确传达信息的必须。 举例来说，我想要更明确和更详细地告诉我爸爸应该如何关闭iPad（“按住右侧的按钮一段时间……”）。或者，我看似多此一举地键入了一些我已经提 交到本地分支的内容给我的同事（“刚刚犯的错误已被修复”），然后当它涉及到部署更新到产品中时，我就能很明确地知道哪些具体的提交被合并和出现（“检查 4812-4822行，其中包括在6/15发行版本中的DoneDone问题，将在今晚的产品发布中提出来。”）。 3.累计良性债务，并且要持续偿还。 我在一个特别害怕欠债的家庭中长大。八十年代中期，我的父母倾其所有又东拼西凑，付了他们第一套房子75％的首付，然后在七年内付清了剩余款项。用现金支付是常态。信用支付在他们看来几乎是一种罪过。作为一个孩子，我的看法是，债务完全是坏的。我从不认为欠债是一种优势。 直到我看到其他人是如何对待债务的——在我20出头的时候——我终于知道了债务也可以是有益的。如果你能够合理地承担债务，那么之后你也能获得成功。如果借助现在更好的上升空间可以加速你之后的成长，那么债务可以成为一笔巨大的财富。 代码也是如此。有时它值得你现在承担一点债务——错过抽象或者有一些未优化的SQL代码——如果这样做可以让你更快地发布内容给不断增长的观众的话。关键是要了解你必须偿还它，以及你可以在适当的时间段之后偿还。 这就是债务在生活和编程中的窍门。偿还债务需要持续进行。将一周10％的时间用于重构，相当于你是在按时支付编码的信用卡账单。如果你保持一种持续、可支撑的还债状态，那么累积债务实际上对你是有好处的。 译文链接：http://www.codeceo.com/article/17-year-3-tips-programming.html 英文原文：Programming’s three life lessons 翻译作者：码农网 – 小峰 from:http://www.oschina.net/news/73943/17-years-code

2016 年你应该学习的语言和框架

2015年，软件开发界发生了很多变化。有很多流行的新语言发布了，也有很多重要的框架和工具发布了新版本。下面有一个我们觉得最重要的简短清单，同时也有我们觉得值得你在2016年花时间精力去学习的新事物的一些建议。 大趋势 在过去的几年里，有一个越来越明显的趋势是web应用的商业逻辑逐步从后端转移到了前端，然后后端变得只需要处理简单的数据API。这就让前端开发框架的选择变得尤为重要了。 另外一个重要的改变是2015年发布的 Edge 浏览器。这是IE的替代品，拥有全新的界面和更好的性能。跟IE不一样的是它同样采用了跟 FireFox 和 Chrome 一样的快速发布策略。这让JavaScript 开发者社区能够以周为单位获得最新版JavaScript 和 Web标准特性支持而不是像过去一样需要等很多年。 语言和平台 Python 3.5 在今年发布了，带来了很多新特性 比如 Asyncio，为你带来了类似 node.js 的事件机制，还有type hints。 鉴于Python 3 终于真正地火起来了我们强烈建议你替换掉 Python 2。几乎所有的库都已经支持 Python 3 了，所以现在是一个升级历史遗留代码的好时机。 PHP 7  是一个重要的新版本，这个版本修复了很多问题并且带来了新特性和性能提升（看看概览） 。 PHP 7 大约比 PHP 5.6 快2倍， 这对一些大型项目还有WordPress 和 Drupal之类的CMS系统影响很大。 我们强烈推荐 PHP之道，已经更新到最新的PHP7版本。 如果你需要更快的速度并且不介意换一个解释引擎的话，可以试试Facebook在用的 HHVM。 JavaScript 也以ES2015 标准 (大家通常叫做 ES6)的形式发布了更新。 为我们带来了激动人心的新功能。 感谢大多数浏览器版本的快速更新， 对 ES2015 的支持已经非常棒了，并且还有 Babel.js 这样的工具可以让你的新代码跑在低版本浏览器上。 Node.js 在这一年变化很多，开发者社区曾经分裂成 Node.js 和 io.js，然后又再度合并。 经历过这些之后的结局就是我们得到了一个有很多代码贡献者积极维护的项目，并且拥有了两个版本的 Node ： 一个稳定的LTS (长期支持) 版本，这个版本注重稳定性，比较适合长期项目和大公司，和一个非长期支持但是最快实现新特征的版本。 Swift 2 在今年初发布了。 这是 Apple 出品的旨在简化 iOS 和 OS X 开发的现代编程语言。 几周前， Swift 正式开源并已经兼容 Linux。这意味着你可以用它来编写服务端应用了。 Go 1.5 在几个月前发布了， […]