本文将介绍Visual Studio的常用快捷键，可以提高工作效率，加快工作速度，产出更多的工作成果。
业务层引入缓存组件实现业务对象的缓存，对外部应该是个黑盒，不需要外部关心使用那种缓存组件，使用的具体细节，哪些场景使用，外部存取业务对象的接口也不应该发生变化，不需要任何缓存相关参数。但是应该允许外部调用者关闭缓存，就是说外部调用者应该可以在初始化业务对象的时候声明不使用业务对象的缓存机制，或者在使用的过程中设置关闭和开启业务对象的缓存机制。 假设我是业务层的调用者，我希望在初始化业务层对象的时候，可以设置是否启用业务对象的缓存机制。同时在使用已经初始化的业务层对象的时候，也可以在需要的时候进行缓存机制的开启和关闭。
缓存使得你可以快速的获取内存中存储的数据。当再次访问数据的时候，应用从缓存中获取数据，而不是从数据的原始源获取。这么做可以提高性能和扩展性。另外，当数据源临时不可用的时候，缓存使得数据还是可用的。 你可以用.NET提供的缓存功能提高应用的性能和扩展性，缓存功能可以在windows客户端应用中使用，也可以在ASP.NET这种服务端应用中使用。
今天主要说三个内容，都是和ASP.NET有关的内容。 第一个关于自定义错误的，就是在网站出现404或者500的错误，如何给用户显示一个友好的界面。 第二个是分离配置文件web.config，如果配置信息很多，都放在web.cofig文件，文件会越来越大，越来越长。信息太多了，不便于浏览和维护，如果能分成独立的config该多好。 第三个是关于多环境发布的，多环境指的是：开发环境，测试环境，生产测试环境，生产环境。利用VS方便多环境的配置文件修改。
现在的手机上网已经很普及，尤其是智能手机，在一些稍大的城市，几乎是满天飞了，在一些中小城市，普及的也比较广。在我国，手机上网用户，已经快达到4亿，可见市场是多么的诱人。 智能手机常见的操作系统有：android，apple os，windows phone，还有以前的symbian，smart phone等。 而且，这两年又加入了一种新的客户端，那就是pad。pad相比较手机而言，屏幕更大，7寸，8寸，10寸，存储空间更大，甚至处理能力更强。 pad的操作系统主要是两种：android和apple os。 手机和pad上网一般都支持手机卡上网，或者是无线连接上网。 所以现在的网站，有相当一部分在建立的时候，就考虑要支持手机浏览。就算是已经建立好的网站，很多也开始考虑加入对手机浏览的支持。更有一些，同时还做了手机客户端，充分利用手机的资源，提供更进一步的服务。
时间戳，也叫做Unix时间戳，就是从1970年1月1日0时0分0秒到当前时间的总秒数。本文介绍了几种情况的时间戳的使用，以及在SQL Server中的一种和时间戳容易搞混的TIMESTAMP。
rails中针对date类型的扩展。
工作1-3年，少走弯路。其实也是结合自己的成长历程想出来的。 这一年有很深的感触，如果自己在工作的初期，可以有一些明确的指导，或者说有见解的人的带动，自己可以少走很多弯路，可以走的更快。虽然说个人的努力与勤奋是必须的，不能等着别人来帮助你，但是如果有人在你努力的同时帮助你，哪怕是指导你一下，你也会走的更好。 虽然说弯路使人成长，使人成熟，但是有些弯路其实可以避免，甚至有些弯路需要避免，没有必要走一走。 甚至夸大点说，少走弯路，可以集中精力做更多的事情，做更多想做的事情，更大的发挥个人的潜力。
ActiviSupport中包含一些工具类，以及一些对标准类库的扩展。 ActiveSupport的内容都是是独立于rails的，因此也可以在非rails的ruby项目中使用。 今天介绍一些针对Array的扩展。
本文主要针对条件处理中的if分支，进行了一种方式的重构。将流水线的场景引入到if处理流程中，针对一个对象的各种if分支处理的时候就可以套用这个改进后的流程。可以得到下面的一些好处： 1.上面代码中的获取订单方法，不会越来越长，这样阅读起来就很好理解，在后面进行维护的时候，就很容易来做了。 2.添加一个新的条件处理分支也很容易，只要把这种条件处理看做是一个闸门，在处理流水线中加入新闸门就可以了，其他的都不需要变化。 3.调整原来的条件处理，也只需要修改闸门内部的处理代码即可，不用担心是否影响其他处理分支。 4.分支独立之后，还可以针对每个分支做单元测试。
本文由ruby-china的一篇帖子“由小数的精度问题引出设计问题”引出，帖子也是我发的，在查看回复的时候学到了不少内容，有了一点感悟，所以就想总结一下。 首先声明本文选用的编程语言为ruby，运行环境是ubuntu。 在编写财务，电子商务之类应用的时候，经常会碰到小数，小数乘、除、加、减的场景。 大多数语言表示小数，都有单精度float，双精度double，还有一个更加精确的decimal，无论是哪一种，都统称为浮点数。 浮点数是一个近似的数值，不是精确的数值。至于为什么不精确，这个涉及到操作系统的底层，和二进制的保存有关。 这就造成了浮点数的比较结果，有时会出现违反生活常识的场景。文中将介绍两个大家常用的解决办法，以及引出来的系统设计问题。
本文首先会介绍如何在应用中添加邮件发送程序，然后再介绍一些邮件发送程序相关的测试该如何进行，以及应该测试哪些内容。 关于邮件测试有下面几个目的 邮件正在被处理，创建或者发送。 邮件的内容是正确的，包括标题，发送人，body等。 在正确的时间发送了正确的邮件。 可以从两个方向来测试邮件，一个是单元测试，一个是功能测试。在单元测试中，我们在一个隔离的环境中运行邮件程序，内容是受控的，然后和模拟数据比较输出的内容。在功能测试中，我们在controller和model中正确的使用邮件发送程序，测试在正确的时间发送了正确的邮件。
今天来介绍一些杂七杂八的测试知识，但是它们是不能错过的。
今天我们来熟悉一下rails的集成测试integration test。 集成测试主要是测试多个controller之间的交互，以及测试应用中比较重要的工作流程，验证这些工作流程是否符合预期的设想。 不像单元测试和功能测试，是自动添加的。集成测试是需要我们手动添加的，rails提供了一个命令, rails generate integration_test , 通过命令就可以在test/integration文件夹创建集成测试。
assert_difference的英文解释是 Test numeric difference between the return value of an expression as a result of what is evaluated in the yielded block. 直译的话就是 测试两个数值的区别。 哪两个数值呢，就是expression的数值。怎么变成一个了？不要着急，一个是block执行之前，一个是block执行之后。 意译一下就是 比较expression的数值在block执行前后的差，看这个差是否是difference 参数指定的值，这个参数是个可选参数，默认值是1。 也可以理解为，block执行之后的expression值 - block执行之前的expression值，看这个差值是否等于difference 指定的值，默认差值为1。assert_no_difference(expression, message = nil, &block) 用来测试block前后，expression的数值是否没有发生变化。
企业招人不是来点击按钮的，是需要这些人做更好的东西，提出更好的意见，提供更好的产品，提供更好的服务。我们打工也不想永远从事简单重复的工作，也希望给企业带来自己的想法，为企业的发展做出自己的贡献，希望企业良好的发展，希望自己有各方面的提升。 双方都提升了，双方都高兴了，这才是双赢了。
之前我们介绍过，rails的功能测试针对的是controller，测试controller的action是否正确的执行。 测试的内容主要是： 测试请求是否正确。 测试用户是否跳转到正确的页面。 测试用户是否验证成功。 测试响应中是否包含了正确的对象。 测试在view中是否给用户显示了适当的信息。
上一篇我们介绍了factory-girl，这是一个很好的工具，可以用来替代rails中的fixtures，用来生成模拟数据。 它直观，易读，易读就易维护。最重要的一点是，它是面向model的，面向业务的，面向应用的，而fixtures模拟的数据是面向数据库的。但是我们的单元测试，功能测试，甚至将来要介绍的集成测试，都是面向业务的，从业务角度出发的测试，测试系统是否满足业务需求。所以好处显而易见了，相信大家在使用了以后会有一点感触。
使用fixtures有几个不利的因素，使得他们处于不利的位置。 最主要的一个因素是，这些fixtures描述的数据和测试他们的行为是分开的，在不同的文件中。使用这些模拟数据，我们需要依赖于fixtures文件，这些文件很难阅读，维护不便。因此很多时候我们使用factory-girl替代fixtures来创建模拟数据。
之前的博客介绍了一些rails测试相关的知识。测试文件的位置，测试的类型，测试常用命令，以及可用的一些资源，以及如何利用fixtures生成模拟数据。 今天我们来实际的写一下单元测试，用到的知识主要是fixtures和unit test。fixtures用来模拟数据，unit test就是我们今天的主角-单元测试。 今天的代码将以blog项目为背景，为这个项目写一些单元测试。 这个项目的代码可以在https://github.com/woaigithub/blog获取到，而且项目已经部署到http://42.121.5.68:10000/，大家也可以直接在部署的生产环境上面写自己的博客。 项目使用ruby on rails开发，开发及测试环境使用sqlite3作为数据存储，生产环境使用mysql作为数据存储。 单元测试 rails的单元测试主要针对model，model是我们的业务实体。单元测试主要测试model的validates，以及model的业务规则，测试经过业务规则的执行，我们的model的变化，就是model的属性值，是否符合规则的描述，是否变为预期的值。
在rails中，针对单个controller中的各个action进行的测试，叫做功能测试。controller处理web的请求，将请求的响应render到view中。
单元测试针对model，主要是测试model中的业务规则，测试model中的验证validates规则。 单元测试的文件存放在test/unit文件夹，针对user的model的单元测试文件是user_test.rb。
fixtures就是用来创建模拟数据的。 这些数据会被插入测试数据库，因此不能模拟数据库不存在的属性。 模拟数据可以在单元测试unit test和功能测试functional test中使用，通过表名(:模拟实体名)就可以访问模拟实体。users(:devid)就是一个user，然后users(:devid).name就可以访问name属性的值。
本章我们从一个cucumber的逻辑错误开始。从外部的cucumber周期，转向内部的rspec周期。 本章我们使用RSpec来完成了一个red/green/refactor的周期。 这就是BDD的周期。从外到里的驱动开发，从使用cucumber描述的业务scenario，到使用rspec描述的内部对象。
我们先在.feature文件中写一个feature的scenario，已经scenario的steps，然后在step_definitions中定义Given，When，Then，然后在通过测试cucumber .feature文件来驱动我们编写实现代码。 当目前为止，我们已经学会使用cucumber从外部描述一件事。在接下来的章节中，我们将会进行从外到里的工作方式，使用RSpec来驱动单个对象的外部行为。
缩小用户故事的范围，保证留下的用户故事和一次发布的目标匹配即可。 为一个interation选择用户故事，不要再一个interation中放入太多的用户故事，不要希望一个interation来完成所有的用户故事。 验收准则，我们通过写cucumber feature来描述用户故事。我们在迭代计划会议期间做这件事，使用这些来确定和修改我们的预估。 scenario outline，使得我们减少大量的重复，更加的DRY。
TDD（Test-Driven Development）测试驱动开发。 在编写代码之前先编写一个测试，这时候测试是失败的，red，因为还没有写对应的实现代码。然后开始编写实现的代码，然后跑刚才写的测试，直到测试通过，green。 然后我们就重构我们的代码，refactor，然后再次跑我们的测试，green重构成功，red重构失败。失败也没有关系，继续重构。而且有了测试的保证，我们可以很放心的重构。 TDD偏激的做法是，在没有编写测试之前，绝不写一行代码。软件开发，测试先行。用测试来驱动开发。 BDD（Behavior-Driven Development）行为驱动开发。 在应用级别，项目的利害关系人通常不关心数据被持久化到什么地方，什么格式，什么存储类型。当然不是说他们不关心数据，而是说他们更关心他们保存的数据，在他们需要的时候可以获取出来。
Rails开发细节《九》Rails的测试
常用命令介绍。
ruby,class,variable,class method,instance method,class variable,instance variable,singleton
Copyright © 2005-2023 51CTO.COM 版权所有 京ICP证060544号
