《Software Engineering at Google》摘抄(1)

by kevin 14. 八月 2022 10:37 >
We propose that “software engineering” encompasses not just the act of writing code, but all of the tools and processes an organization uses to build and maintain that code over time.(我们建议,"软件工程 "不仅包括编写代码的行为,还包括一个组织用来长期构建和维护代码的所有工具和流程。) The book emphasizes three fundamental principles that we feel software organizations should keep in mind when designing, architecting, and writing their code: Time and Change How code will need to adapt over the length of its life Scale and Growth How an organization will need to adapt as it evolves Trade-offs and Costs How an organization makes decisions, based on the lessons of Time and Change and Scale and Growth(本书强调了三个基本原则,我们认为软件组织在设计、架构和编写代码时应该牢记这些原则: 时间和变化​代码如何展期生命周期内进行适配。 规模和增长​一个组织如何适应它的发展过程。 权衡和成本​一个组织如何根据时间和变化以及规模和增长的经验教训做出决策。) We see three critical differences between programming and software engineering: time, scale, and the trade-offs at play. On a software engineering project, engineers need to be more concerned with the passage of time and the eventual need for change. In a software engineering organization, we need to be more concerned about scale and efficiency, both for the software we produce as well as for the organization that is producing it. Finally, as software engineers, we are asked to make more complex decisions with higher-stakes outcomes, often based on imprecise estimates of time and growth.(我们看到,编程和软件工程之间有三个关键的区别:时间、规模和权衡取舍。在一个软件工程项目中,工程师需要更多关注时间成本和需求变更。在软件工程中,我们需要更加关注规模和效率,无论是对我们生产的软件,还是对生产软件的组织。最后,作为软件工程师,我们被要求做出更复杂的决策,其结果风险更大,而且往往是基于对时间和规模增长的不确定性的预估。) We can also say that software engineering is different from programming in terms of the complexity of decisions that need to be made and their stakes. In software engineering, we are regularly forced to evaluate the trade-offs between several paths forward, sometimes with high stakes and often with imperfect value metrics. The job of a software engineer, or a software engineering leader, is to aim for sustainability and management of the scaling costs for the organization, the product, and the development workflow . With those inputs in mind, evaluate your trade-offs and make rational decisions. We might sometimes defer maintenance changes, or even embrace policies that don’t scale well, with the knowledge that we’ll need to revisit those decisions. Those choices should be explicit and clear about the deferred costs.(我们还可以说,软件工程与编程的不同之处在于需要做出的决策的复杂性及其风险。在软件工程中,我们经常被迫在几个路径之间做评估和权衡,有时风险很高,而且价值指标不完善。软件工程师或软件工程负责人的工作目标是实现组织、产品和开发工作流程的可持续性和管理扩展成本为目标。考虑到这些投入,评估你的权衡并做出理性的决定。有时,我们可能会推迟维护更改,甚至接受扩展性不好的策略,因为我们知道需要重新审视这些决策。这些决策应该是明确的和清晰的递延成本。) So, concretely, how does short-term programming differ from producing code with a much longer expected life span? Over time, we need to be much more aware of the difference between “happens to work” and “is maintainable.” There is no perfect solution for identifying these issues. That is unfortunate, because keeping software maintainable for the long-term is a constant battle.(那么,具体来说,短期编程与生成预期生命周期更长的代码有何不同?随着时间的推移,我们需要更多地意识到“正常工作”和“可维护”之间的区别。识别这些问题没有完美的解决方案。这是不幸的,因为保持软件的长期可维护性是一场持久战。) If you are maintaining a project that is used by other engineers, the most important lesson about “it works” versus “it is maintainable” is what we’ve come to call Hyrum’s Law: With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.(如果你正在维护一个由其他工程师使用的项目,那么关于“有效”与“可维护”最重要的一课就是我们所说的海勒姆定律: 当一个 API 有足够多的用户的时候,在约定中你承诺的什么都无所谓,所有在你系统里面被观察到的行为都会被一些用户直接依赖。) Everything your organization relies upon to produce and maintain code should be scalable in terms of overall cost and resource consumption. In particular, everything your organization must do repeatedly should be scalable in terms of human effort. Many common policies don’t seem to be scalable in this sense.(你的组织生产和维护代码所依赖的一切都应该在总体成本和资源消耗方面具有可扩展性。特别是,你的组织必须重复做的每件事都应该在人力方面具有可扩展性。从这个意义上讲,许多通用策略似乎不具有可扩展性。) This type of approach might work in a small software setting but quickly fails as both the depth and breadth of the dependency graph increases. Teams depend on an ever- increasing number of Widgets, and a single build break can affect a growing percentage of the company. Solving these problems in a scalable way means changing the way we do deprecation: instead of pushing migration work to customers, teams can internalize it themselves, with all the economies of scale that provides.(这种方法可能适用于小型软件项目,但随着依赖关系图的深度和广度的增加,很快就会失败。团队依赖越来越多的小部件,单个构建中断可能会影响公司不断增长的百分比。以一种可扩展的方式解决这些问题,意味着需要改变我们废弃的方式: 不是将迁移工作推给客户,团队可以将其内部消化,并提供所需资源投入。) One of the broad truths we’ve seen to be true is the idea that finding problems earlier in the developer workflow usually reduces costs. Consider a timeline of the developer workflow for a feature that progresses from left to right, starting from conception and design, progressing through implementation, review, testing, commit, canary, and eventual production deployment. Shifting problem detection to the “left” earlier on this timeline makes it cheaper to fix than waiting longer, as shown in Figure 1-2.(我们看到的一个普遍真理是,在开发人员的工作流程中发现的问题,通常可以降低成本。考虑开发人员工作流程的时间表,从左到右,从概念和设计开始,通过实施、评审、测试、提交、金丝雀和最终的生产部署来进行。在此时间线之前,将问题发现转移到“左侧”会使修问题解决成本更低,如图1-2所示。) What do we mean by cost? We are not only talking about dollars here. “Cost” roughly translates to effort and can involve any or all of these factors: Financial costs (e.g., money) Resource costs (e.g., CPU time) Personnel costs (e.g., engineering effort) Transaction costs (e.g., what does it cost to take action?) Opportunity costs (e.g., what does it cost to not take action?) Societal costs (e.g., what impact will this choice have on society at large?) 我们所说的成本是什么呢?我们这里不仅仅是指金钱。“成本”大致可以转化为努力的方向,可以包括以下任何或所有因素: 财务成本(如金钱) 资源成本(如CPU时间) 人员成本(例如,工作量) 交易成本(例如,采取行动的成本是多少?) 机会成本(例如,不采取行动的成本是多少?) 社会成本(例如,这个选择将对整个社会产生什么影响?)

最近阅读 2022-01-23

by kevin 23. 一月 2022 10:20 >
新鲜 浮动房屋 荷兰是一个洼地国家,大部分国土不高于海平面,所以经常淹水,并且住房短缺。该国建筑师正在尝试,在水面上架设住宅。 他们在首都阿姆斯特丹的河道里面,建了46套浮动住宅。这种房子架在钢柱上面,可以随着水位上下浮动,所以不担心涨水。 古埃及凳子 大英博物馆收藏了一个3500年前的古埃及凳子。这个凳子是用木头做的,保存情况之良好,令人震惊。 到处都是窗的建筑 日本德岛县上胜町的资源回收中心,是一个木结构建筑。除了建筑主体的木材,其它建筑材料都使用了当地的废弃物品,比如地面使用了回收的玻璃和陶器。 它最引人注目的地方,就是整个建筑有700多扇窗子,都来自以前的老屋子。   资源分享 中华古籍资源库 http://www.nlc.cn/pcab/zy/zhgj_zyk/   2020 年全球森林资源报告 https://www.fao.org/forest-resources-assessment/2020/zh 言论 一个可运行的复杂系统,总是从一个简单系统演变而来的。似乎可以因此推断:从头开始设计一个复杂系统,永远不会奏效,必须从一个简单系统开始设计。 大师并不是一开始就是大师。你把他们早期第一阶段的作品找出来看看,就会了解他们取得了多大的进步。 对于非虚构类书籍,作者的写作能力与书籍销量无关。事实上,一个作者如果写得简明扼要,完全可以将一本350页的非虚构类书籍,简化成一篇40页的长文,但是这样的话,书价就到不了15美元了,而且销量也会比较小。 假设做一个调查,观察周围的人,如果他的主张可能是错的,他会改变看法,还是会坚持原来的主张?几乎所有人都选择,设法证明自己原来的主张没错。

最近阅读 2021-04-15

by kevin 15. 四月 2021 14:04 >
工具 Maya是一款体积小巧、简单易用的快速启动工具。 https://github.com/25H/Maya 学习 《苏世民:我的经验与教训》读书笔记 https://zhuanlan.zhihu.com/p/129251976 Burp Suite 实战指南 https://t0data.gitbooks.io/burpsuite/content/ 资源分享 卢浮宫作品 https://collections.louvre.fr/en/ 言论 知识的诅咒(Curse of knowledge)是一种认知偏差,指的是与他人交流时,你不知不觉地假设对方拥有跟你相似的认知,能够理解你的意思。 其实弱者并不可怕,可怕的是被悲观情绪主导思想的宿命论者。 生活的悲剧不在于人们受到多少苦,而在于人们错过了什么。 我们犯过的最大的错误不是做错了什么,而是该做的没做。 穷人所陷入的困境与我们其他人的困扰似乎是一样的——缺乏信息、信念不坚定、拖延。的确,我们并不贫穷,受过良好的教育,见多识广,但我们与穷人的差别其实很小,因为我们的认识比我们想象中的要少很多。我们的真正优势来自于,很多东西是我们在不知不觉中得到的。 所有小说写的都是真事。怕吓着你们才叫小声说。 “工作时间”不应该用劳动的艰苦程度来界定,而应该用劳动者“受雇主支配”的时间段来界定。 有时我们的眼睛可以看见宇宙,却看不见社会底层最悲惨的世界。 写作过程分为两个阶段:发散和收敛。在发散阶段,你自由地探索新想法;在收敛阶段,你变得专注,将想法尽量简化,以便将其发布。我最喜欢的一句写作格言:收集点,然后连接点。

读完《闺蜜》记下了这些

by kevin 22. 四月 2013 23:02 >
-- 艾明雅的《闺蜜》 她想,有些梦想可能永远都不会实现了。她想,有些梦想也许明天就可以实现了。 没有一个男人不是在女人的怀抱里长大的。 我不会在一开始,就莫名其妙的对一个女人好。 我还是个善良的姑娘,也还是个柔软的姑娘,只是多了一层坚硬的,不那么光彩的,看起来嚣张戾气与精明世故的壳。 错过是比错爱更难以面对的事情。 从烟花到烟火,你用了几年。 有个女孩叫萝莉,她只爱大叔。 你看(见)我的笑话,我目睹你的惆怅。 你路过,我走过,都没有细问过。 我珍重与你在一起的时光,(也懂得)把未来交给上苍。 我不扶你,你往前走,我会一直在你身边。 我愿逆流而上,我愿在她身旁。想起闺蜜,心中无比欢畅。 感情的事,只有靠感情才能解决。 女人希望她被爱的原因是她是个女人。 做婚姻的好榜样,不要轻言放弃。 年轻的女子大都有一段伪文艺的日子。 花言终究是花言,巧语毕竟是巧语,骗得了女人,却骗不了人性。 你下车后,我说再见,是真的想要再见面。 请你在繁华的都市里,活的好好的。 认识计划并非人生本事,计划来,计划去,还要注意的,是缘分永远无法被计划。 一旦成家立室,男人总比女人显得灵动。 做饭,是不让生活潦倒的第一步。 想要认真面对感情生活,想要给自己一个归宿。 那些转折点,最好都要有一个人,愿意陪着你走下去。 为人妻为人母,名分只是他给,而戏依旧是自己在唱。 没有人是天生的好老公,也没有人是天生的好老婆。 我从来不知道要怎么对待老婆,因为我从来没有过老婆。 我忧伤过,放弃过,桀骜过,痴迷过,追寻过,迷茫过,埋怨过,绝望过。

《商业的常识》印象笔记

by kevin 23. 三月 2013 06:49 >
读了两遍申音先生的《商业的常识》,收获了一下这些。 创业是一胜九败的事,创业不是一件风光的事。 媒体写出来的不是最悲催的故事,就是最光荣的典范,其实创业者大部分的时间是在常态中,就是熬着。 道德感跟成功确实没有太大的关系。 人们的第一次成功往往根源于欲望和运气,而更多的成功则需要智慧和自控。 创新的前提是思想的真正解放。 懂货,懂技术,懂物流,懂营销。 事实上,创业中那些最关键的技能,都是非标准化的,不以言传的。 机会在于商业环境的变化。 当一个企业成功后,才有资格总结他的商业模式。 如何从一件流行的事物上赚钱要比如何使一件事物流行起来容易很多。 谁是商业模式他妈?  那些英文好,密切接触国际产业前沿的海归往往有先发优势。 商业模式是讲给投资人听的,VC比你更需要创业模式。因为你关心自己的事业,而他们要管好别人的钱。 当你在写商业计划书的时候,实际上是把你对于现实的理解和未来的想象用完全商业的思维工具表达出来。 免费的阴暗面,想尽办法利用人性的阴暗面,一家独大。 对于大多数创业者而言,最要命的问题是有足够的钱来维持公司的运转。 从平凡到优秀,从优秀到卓越。 在一个足够细分的领域,都存在著名的或者不著名的真知灼见者。

程序员如何入门SEO

by kevin 20. 二月 2013 04:04 >
      SEO是搜索引擎优化(Search Engine Optimization)的缩写,坊间传说的网络推广的神器。每每想多了解一些,总是找不到门路,直到某天,在亚马逊买书时偶然看到昝辉Zac先生的《SEO实战密码》,所以就买了一本,这篇博文是我读完这本书的一些体会。       SEO到底是什么呢?SEO是指在了解搜索引擎自然排名机制的基础上,对网站进行内部及外部的调整优化,改进网站在搜索引擎中的关键词自然排名,获得更多流量,从而达成网站销售及品牌建设的目标。在某种意义上看,SEO是和搜索引擎博弈的过程,是从自然搜索结果获得网站流量的技术和过程。         为什么要做SEO?SEO是给网站带来访问者的最好方法,没有之一。性价比高,访客质量高,而且长期有效。         如何进行SEO?作为程序员,可以通过这样的方式进阶。网站结构优化,页面优化,外部链接的建设,竞争研究。无论哪个阶段,都需要进行效果监测,包括流量监测和非流量监测。         网站结构优化,是从搜索引擎访问网站的方式入手,对这个网站结构进行优化。需要理解搜索引擎的爬虫如何找到网页,如何抓取页面的内容,又是如何提炼页面有用信息的。还要了解一些爬虫陷阱,例如,使用图片或者Flash进行表现,根据cookie或者session表现不同内容,不同的URL跳转方式也会有不同的影响等。        页面优化则是为了让搜索引擎更好的阅读网页内容。要进行页面优化,重要的是要知道不同的html标签对于搜索引擎的意义。比如<h1>到<h6>都是权重比较高的标签。        外部链接是帮助搜索引擎判断什么样的页面更有价值。链接是互联网最本质的特性之一。理论上,优质的内容,指向它的链接自然就比较多。所以更多的外链数,就意味着更优质的内容。另外,还需要理解链接分析技术,外部链接的制作方法。        竞争研究则是把对关键字进行分析,得出内容和关键字的最佳匹配。这部分对于程序员来说,是最难的。因为知识跨度比较大,基本上只关键词的选择开始学起。         SEO的直接目的是获得流量。所以流量监测比不可少,这个可以通过一些第三方统计脚本来完成。比如,百度统计或者google analytics。         SEO的最终目的不是获得网站流量,而是完成转化,达到直接销售或者品牌建设。所以在优化前要制定一些营销目标,优化后做一些检测评估。         当然,学习SEO不只是这些,同时还有很多工具需要去掌握,包括,xenu,Alexa,谷歌趋势,百度指数等等。         先写这些了,有新的理解,再续。

2012读过的好书

by kevin 17. 一月 2013 01:49 >
.thisimg{ width:92px; height:120px; display: block; margin: 10px auto; } .thistable{ border: 0px; width: 600px; margin:center; } .thistable a{ color: #b8e1e1; } .thistable div{ margin-left:10px; line-height:18px; } .thistable span{ color:#33cccc; } .thisname{ margin-top:5px; } .thisauthor{} .thiscontent{} .thispublishing() .thiscomment{} 书呆一个,2012买了很多书,看了一些,稍微回顾一下,觉得这些不错,推荐给大家。 学习之道 作者:乔希•维茨金, 苏鸿雁 (译者), 谢京秀 (译者) 出版社:中国青年出版社 内容简介:终身学习,为了更幸福更体面的生活。在竞争激烈的高阶领域,决胜关键不仅在于知识多寡,还包括心理层面的锻炼:承受压力、把阻力化为优势,以及体能和情绪迅速复原的能力。而真正的学习赢家,能够在追求卓越的过程中持续吸收心得,最终以健康的心态和纯熟的技巧,表现出最好的自己。 评语:让我印象最深的是如何让大脑冷静那部分,还有如何让对手动作变慢。做为一个喜欢思考的人,都值得一看。 布道之道 作者:瑞恩(Terrence Ryan)、李缨 (译者)、 李松峰 (译者) 出版社:人民邮电出版社 内容简介:在IT行业打拼,每个人都可能遇到这种情况:你用了一种新技术或新工具,工作效率倍增,于是迫不及待地想让自己的同事和团队都赶紧试一试。但刚一提出这件事,就有很多人抵制。如何看透怀疑者的心理?如何说服别人接受你的提议?这就是《布道之道:引领团队拥抱技术创新》要告诉你的。 评语:练习说服别人的技巧特别重要,特别是在你需要表达正确意见的时候。 每天懂一点色彩心理学 作者:原田玲仁、郭勇 (译者) 出版社:陕西师范大学出版社 内容简介:本书的内容虽然以高深的理论为基础,但尽量避开了晦涩难懂的复杂部分。通过许多生动活泼、简单实用的例子,本书将色彩心理学的核心思想与思维方式直接明了地展现在读者面前。书中的插图和漫画也是为了让读者能够更加轻松地阅读而精心绘制的。 评语:我这个IT男看了这书后收获是很大,对你买衣服,装饰房间的都很有用。 Erlang/OTP并发编程实战 作者:洛根(Martin Logan)、梅里特(Eric Merritt)、卡尔森(Richard Carlsson)、 连城 (译者) 出版社:人民邮电出版社 内容简介:主要分为三大部分:第一部分讲解Erlang编程及OTP基础;第二部分讲解如何在实际开发中逐一添加OTP高级特性,从而完善应用,作者通过贯穿《Erlang/OTP并发编程实战》的主项目——加速Web访问的分布式缓存应用,深入浅出地阐明了实践中的各种技巧;第三部分讨论如何将代码与其他系统和用户集成,以及如何进行性能调优。 评语:erlang开发人员必读 企业应用架构模式 作者:福勒(Martin Fowler) (作者), UML China (合著者), 王怀民 (译者), 周斌 (译者) 出版社:机械工业出版社 内容简介:作者是当今面向对象软件开发的权威,他在一组专家级合作者的帮助下,将40多种经常出现的解决方案转化成模式,最终写成这本能够应用于任何一种企业应用平台的、关于解决方案的、不可或缺的手册。 评语:理论的东西,可以认识很多的概念,术语。还可以了解下企业开发一般会碰到的问题。 硝烟中的Scrum和XP 作者:克里伯格(Henrik Kniberg) (作者), 郑柯 (注释 解说词), 李剑 (译者) 出版社:清华大学出版社 内容简介:源自真实的故事,Henrik Kniberg以过来人的身份,回顾了他在一年时间内带领40人团队实施敏捷转型和持续过程改进的亲身经历。在Henrik的领导下,团队经历了不同的规模,不同的sprint长度,不同的定义“done”的方式,不同格式的产品backlog和sprint backlog,不同的测试策略,不同的演示方式,同步多个Scrum团队工作的不同方式,如此等等。 评语:很多人谈敏捷,觉得那是虚的,这本绝对实实在在。 立体人脉 作者:袁岳 出版社:龙门书局 内容简介:资深社交达人首次提出立体人脉概念,从三维角度对人脉的建立、拓展、管理等方面进行了准确的解读,内容涵盖了职场新人建立自己的人脉圈所要注意的方方面面,描绘了一张青年读者如何建立自己人脉的蓝图,教你从错综复杂的人脉关系网中拨乱反正,依靠正确的人脉走上人生辉煌的康庄大道。 评语:作者是我的偶像,觉得自己在交际上捉襟见肘,就去买了本看。很适合IT男的一本书。 一个人住的每一天 作者:高木直子 (作者), 顾峰峰 (译者) 出版社:辽宁科学技术出版社 内容简介:不管是出于什么原因开始一个人生活的,最多的,应该是考上了离家比较远的学校;又或者是想趁着工作的机会独立起来;还有一些是因为工作调动;甚至有些人只是单纯很向往一个人的生活;当然,还有很多除了这些以外的其他原因……一个人的生活有着怎样的苦辣酸甜?快乐或心酸,孤独或惬意,所有的感受都在那个小家里悠然而生,又在那个小家里渐渐消失。 评语:每个人都有一个人住的时候。 深入学习MongoDB 作者:Kristina Chodorow (作者), 巨成 (译者), 程显峰 (译者) 出版社:人民邮电出版社 内容简介:第一部分全面讲解了有关建立和使用集群的内容,不仅从应用开发人员的角度讲解了MongoDB的使用,而且从运维方面介绍了集群的管理。其中内容包括通过分片设置MongoDB集群,分片的工作原理,查询和更新数据,操作、监控和备份集群,错误处理。第二部分依次从应用设计、实现、优化、数据安全和管理方面介绍了使用MongoDB构建应用的技巧,内容包括范式化与反范式化的利弊权衡,复制组的故障恢复等。 评语:如果你在使用mongodb,那么非看不可,如果你在NoSQL,那么也看一看,如果你SQL Only,看看也不错。 软件随想录 作者:Joel Spolsky (作者), 阮一峰 (译者) 出版社:人民邮电出版社 内容简介:从不同侧面满足了软件开发人员、设计人员、管理人员及从事软件相关工作的人员的学习与工作需要。 评语:挨踢的,看内容简介,你就懂的。 高性能MySQL 作者: Baron Schwartz (作者), Peter Zaitsev (作者), Vadim Tkachenko (作者), Jeremy (作者), D.Zawodny (作者), Arjen Lentz (作者), Derek J.Balling (作者), 李军 (译者), 王小东 (译者), 康建勋 (译者) 出版社:东南大学出版社 内容简介:可以帮助MySQL初学者提高使用技巧,更为有经验的MySQL DBA指出了开发高性能MySQL应用的途径。全书包含14章和4个附录,内容覆盖MySQL系统架构、设计应用技巧、SQL语句优化、服务器性能调优、系统配置管理和安全设置、监控分析,以及复制、扩展和备份/还原等主题,每一章的内容自成体系,适合各领域技术人员作选择性的阅读。 评语:必读,不解释。 程序员的数学 作者:结城浩 (作者), 管杰 (译者) 出版社:人民邮电出版社 内容简介:面向程序员介绍了编程中常用的数学知识,借以培养初级程序员的数学思维。读者无需精通编程,也无需精通数学,只需具备四则运算和乘方等基础知识,就可以阅读《程序员的数学》。 评语:程序员要多多少数学,这本书给了答案。 SEO实战密码 作者:昝辉Zac 出版社:电子工业出版社 内容简介:详细、系统地介绍了正规、有效的SEO实战技术,包括为什么要做SEO、搜索引擎工作原理、关键词研究、网站架构优化、外链建设、效果检测及策略修正,以及作弊与惩罚、排名因素列表、常用的SEO工具、SEO项目管理中需要注意的问题等专题,最后提供了一个非常详细的案例供读者参考。 评语:SEO入门必备读物。

Tags: ,

读书

程序员与数学--初阅《程序员的数学》

by kevin 25. 十二月 2012 08:13 >
    做为一个程序员,很多时候,碰到问题时,都会后悔自己当初没把数学学好,也经常在思考程序员需要了解多少的数学知识才算是足够的。结城浩写的《程序员的数学》,就是为了回答这个问题的。书中提到:如果数学不好,是否可以成为一名程序员呢?答案是肯定的。编程的基础是计算机科学,而计算机科学的基础是数学。因此,学习数学有助于巩固编程的基础,写出更健壮的程序。 这个观点,我也是比较赞同的。所以也就耐着性子把这本书看了一遍。       这本书,有点像一般的计算机专业本科数学相关教程的复习笔记,比课本要好的一点,是结合了很多实际的例子。所以看看吧,就当复习。,立此存照。   0的特殊意义 标准化,统一规则。比如:100=1。 占位,表示,没有或者不存在的东西。比如:今天不用上课,表示成今天的上0节课。 周期性问题以及分组 实际开发过程中,很多时候会碰到周期性的问题,这个需要我们自己去猜想问题的周期是什么? 比如:今天是星期天,10100的天之后是星期几? 100 –> 星期一 101 –> 星期三 102 –> 星期二 103 –> 星期六 104 –> 星期四 105 –> 星期五 106 –> 星期一 107 –> 星期三 108 –> 星期二 109 –> 星期六 1010 –> 星期四 1011 –> 星期一 1012 –> 星期三 好不容易可以看出,周期是6。100 ÷ 6 = 16 余 4,所以10100的天之后是星期四。   排列组合,递归,数学归纳法 经常碰到吧,是不是已经忘光了,改天看书吧。 很好用哦,努力掌握吧。 最后,回答一个高深的问题,数字在程序开发中起什么作用? 1.思维训练,让程序员具备认识问题,抽象问题的思想。 2.数学建模,让程序员具备解决问题的能力。 所以才说,程序员可以不懂数学,但懂数学对你写程序有非常大的作用。 其他相关的文章: Google首席Java架构师谈数学与程序员的关系 http://developer.51cto.com/art/201012/238798.htm 浅谈程序员的数学修养 http://www.builder.com.cn/2008/0303/751666.shtml

《思考的技术:思考力决定竞争力》摘抄

by kevin 6. 十一月 2012 04:47 >
经营管理顾问的工作,从分析业界数据,企业数据开始,然后再分析结果为基础进行思考。 最糟糕的是试图改善所有不好的现象 你认为你们公司应该解决的最大的问题是什么? 如果你的职位比现在的高两级,为了解决这个问题,首先你会做什么?但是你的公司为什么不这么做呢? 在说明中给客户的建议,只要有一个就够了,同时给他们多个建议,让他们犹豫不决。 你只有一分钟面对总裁,你会做些什么? 事实上,要逼对方做决定,也不是一件困难的事,就算这个决定不是对方所喜欢的,但是事实摆在眼前,对方也没有辩驳的余地了。 为了要看得到成果,我们绝不能忽视人的情绪问题 实际进行提案时,如何安排整体的流程结构是非常重要的。流程安排不当,很容易让参加的公司高层,各部门产生反感。

《立体人脉》读后感

by kevin 5. 十月 2012 19:14 >
前后一个月的时间,读读停停的,终于读完了一遍 @袁岳 老师的立体人脉:人际关系中的空间心理效应。感触颇多,故作此文。 社会中的人不只属于你自己。一句话,说清楚了我们为什么要参与社交活动。社交这个额尔东西,会的时候似乎不是个正经的知识体系,可一旦在你缺失或者薄弱的时候,就会显得哪哪都不合适。这种场景,历历在目。作为80后的我,真的是小时候父母不鼓励甚至反对社交,读书的时候,也不重视,看不起社交。所以进入社会后,给自己加了一层无形的阻力。 《遇的境界》这篇文章用讲禅的方式概括的描述了社交中的方方面面。我们总会在这个世界上遭遇点什么,我们或者够幸运而有两三人对我们有知遇之恩,或者我们也可能不走运而遇人不淑,但是既然“遇”是我们生活中很有可能发生的,那么久让我们为它留下足够的空间吧,我们或者随遇而安,或者遇强则强遇弱则弱。我们只要在开放的路上,我们就会遇见,而且遇到的机会与麻烦、资源与危险的概率几乎是一样高的。《信用是一种行动技术》说明了,行动是赢得信用的最重要途径。《合作伙伴的伦理》则告诉我们如何对待工作或者创业中的合作伙伴。《给社交新手的十三点提示》《场面社交的十个常识》讲的就是实实在在的社交技巧。《通情之心很重要》则在提醒我们要注重对位思考。《做老大的四种条件》是写给那些有心做大佬的人。《女生社交七项注意》则是给初入社会的女孩子们的一些建议。《从生人到熟人的加工流程》告诉我们如何认识陌生人。《小孩也要懂社交》是给那些年轻的爸爸妈妈看的。除了这些,还有一个篇章是描述外国朋友的,另外一个篇章是讲述一些社会群体的。 在社交中反思与提升自己,帮助与支持他人,这就是我们维护人脉,发展社交的真谛了。 注:上文中斜体字摘自《立体人脉》原文

打赏请我喝果汁咯

支付宝 微信

关于我

80后,单身,平庸的程序员。

喜欢看书,乐于交友,向往旅游。

遇建Kevin

FluentData交流群:477926269

Fluentdata