分类 日常 下的文章

本文档假设你熟悉HTML和基本网络知识。
为了构建一个好的计算机系统编写脚本是必要的。Unix的扩展能力来自于shell脚本和各种自动化命令和脚本组成的工具，这也是其很成功的一个原因。现今为了能自动从Web获取信息而伪造用户来提交或者上传数据到Web服务器是一件很重要的工作。
curl是一个重要的命令行工具，用于做各种URL操作和传输，但是本文档将聚焦于怎样用它去发起HTTP请求。这里假设你知道如何使用curl
--help或者curl --manual来获取关于curl的基本信息。
curl不是用来为你做任何事情的，它用于发起请求、获取数据、发送数据和返回信息。你可能需要使用某种脚本语言或者重复手动调用将这些事情粘合在一起。
一、HTTP协议
HTTP是一种用于从Web服务器获取数据的协议。它是一种非常简单地协议，构建于TCP/IP之上。该协议允许客户端使用一些不同的方法获取信息发送到服务器。
客户端发送纯ASCII文本行HTTP请求给服务器，在实际请求内容返回给客户端之前，服务器返回一些文本行给客户端。
客户端可以利用curl发送一个HTTP请求。该请求包含一个方法（比如GET、POST、HEAD等）、一些请求头和请求体（不是必须的）。HTTP服务器回应一个状态行（指示请求状态）、回应头和回应体（大多数时候包含）。body部分是请求的纯数据，比如实际的HTML或者图片等。
使用curl的选项--
verbose（-v）来显示curl有哪些命令和相关解释信息。--verbose很简单，可以用于debug或者理解curl<->server之间的交互。但有时候仅仅有
--verbose还不够，所以--trace和--trace-ascii经常用于显示curl发送和接收的更多详细信息，像这样来使用它：
curl --trace-ascii debugdump.txt

二、URL
统一资源定位符用于指定特定资源在Internet上的地址，比如：http://curl.haxx.se或者。

三、获取page
最简单最普通的请求/操作是使用HTTP获取URL，这个URL本身可能指向一个Web页面、一个图片或者一个文件。客户端发起一个GET请求到服务器，并且接收请求到的文档，这个请求命令行如下：
curl http://curl.haxx.se
你可以在终端窗口中获取到一个Web页面（整个HTML文档）。
所有HTTP回应包含一组响应报头，通常是隐藏的，使用curl的选项--include（-i）来显示它们以及文档的其余部分。也可以用--
head（-I）选项来仅仅获取响应报文头。

四、表单
1、GET
假设有如下表单：

URL地址是，那么用curl就可以如下来发起GET表单请求了：
curl "http:///junk.cgi?birthyear=1905&press=OK"
2、POST
假设有如下表单：

URL地址是，那么用curl就可以如下来发起POST表单请求了：
curl --data "birthyear=1905&press=%20OK%20" hotmail.com/when/junk.cgi
如果你的data数据需要urlencode，那么curl也会帮你做好，具体如下：
curl --data-urlencode "birthyear=1905&press=%20OK%20"
hotmail.com/when/junk.cgi
如果你的后台HTTP服务接收body为二进制的protobuf数据，可以如下方式来发送POST请求：
curl -H "Content-type: application/x-protobuf" -X POST --data-binary
@pb41884288/41884288_1.pb xxx.com/bid
3、表单文件上传
假设文件上传的表单如下：

那么可以如下来上传文件：
curl --form upload=@localfilename --form press=OK [URL]

五、HTTP上传
上传数据到HTTP服务最好的方式是使用PUT方法，当然前提是服务端有程序或脚本知道如何接受HTTP PUT流。
用curl可以如下来上传文件到HTTP服务：
curl --upload-file uploadfile receive.cgi

六、HTTP认证
1、基本认证
如下来用curl使用用户名和密码来认证：
curl --user name:password example.com
上面方法的缺陷显而易见，用纯文本明文传输密码，这种认证方式很不安全。
2、代理认证
如果HTTP访问需要走HTTP代理，那么可以如下来通过代理认证：
curl --proxy-user proxyuser:proxypassword curl.haxx.se
如果代理认证需要使用NTLM方法，那么参数用--proxy-ntlm，如果需要使用摘要认真，那么参数用--proxy-digest。

七、HTTP头
有时需要在HTTP Request之中，增加一些头信息。
1、Referer
如果你需要在http request头信息中，提供一个referer字段，表示你是从哪里跳转过来的，可以如下：
curl --referer example.come example.com
2、User Agent
有时候服务器需要知道客户端的设备信息，服务端会根据不同的客户端设备返回不同的网页，移动互联网时代常见的是手机版和PC版网页，那么用curl可以模拟不同的设备，具体操作如下：
curl --user-agent "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" [URL]
3、header
header参数也可以用来为http request增加头信息，具体如下：
curl --header "Host:" example.com
curl --header "Destination: "
也可以通过参数-H来指定k/v header信息，具体如下：
curl -v xxx.com/bid?p=1&s=2 -H "NS-Client-IP:125.39.240.113"

八、重定向
浏览器能识别302跳转来根据response头中的location来作重定向，还可以通过JavaScript来做跳转，而curl本身并不直接支持，但是可以用如下方式来模拟：
curl --location example.com

九、cookie
curl也支持发送cookie到服务端，具体如下：
curl --cookie "name=scq" example.com

十、HTTPS
curl通过如下方式来发起HTTPS请求：
curl https://secure.example.com
如果HTTPS需要证书可以如下：
curl --cert mycert.pem https://secure.example.com

更多信息请参见官网，还可以参见这里，也可以参见这里，还有。

今天逛博客园，看到一篇面试官问：程序画面怎么和权限结合起来？去年用ZendFramework做的一个投资管理系统权限模块关键思路分享给大家。

因为是总公司的一个项目，内部使用。所以就不存在市场调研，我主要负责获取资源,建立项目时间点,跟踪进展情况,确定关键路径,在需要时获得额外资源,与管理层保持沟通，需求整理，用例图，当时团队人不是很多，测试也自己包了。

下面是那原博文链接
http://www.cnblogs.com/nianming/p/3369280.html

1.管理系统权限角色：要求有默认用户属于风控 股东 业务员 财务其中一个角色，其中每个用户的权限可能会因业务需求发生变化，下面是分配权限界面。


2.流程

3.核心代码

点击(此处)折叠或打开



classPlugin_AclAccessextendsZend_Controller_Plugin_Abstract
{
public function preDispatch(Zend_Controller_Request_Abstract $request)
{
$login=new Zend_Session_Namespace('member');
$cont=$this->getRequest()->getControllerName();
$action=$this->getRequest()->getActionName();
/*Initializeactioncontroller here*/
if(!in_array($cont."_".$action,array("member_login")))
{
if(!$login->name){//如果Session中的name值存在
//执行后跳转至信息提示页面，并且指定ID值为 loginno
header("Location: ".SITE_URL."/member/login");
exit('Access Denied');//结束当前访问
}
}
$acl_config=new Zend_Config_Ini(APPLICATION_PATH.'/configs/acl.ini',"config");
$admin_list=explode(",",$acl_config->adminlist);
if(!empty($login->uid)&&!in_array($login->name,$admin_list))
{
$this->_CheckAccess($login->uid);
}

}

这套系统前后总共用了三个多月，前期预计是两个月，后来因为一个程序离职，加长了项目项目时间。初期的框架是我选择与搭建的，后面基本没怎么参与，因为是管理系统属于个性需求，目前市场上又没找到类似的开源。最后决定重新自己用ZF框架来写，费了很大劲。如果项目比较赶的话，建议还是用开源程序改，至少用户表，登录机制不用自己重新写了，团队的同鞋们辛苦了。

这套广告管理系统可能用到5-8年了，很多操作效率非常低，系统逻辑性也存在一些问题，导致刚入职的新员工学习成本很高，准备给把这套系统重写，改善体验。

1.原系统截图

2.整理出系统所有栏目以及页面

3.为了操作便捷，引入了概况，桌面概念。

  1. 桌面：类似windows桌面，是所有总栏目的导航。
  2. 概况：最近的一些消息，类似于通知。比如广告客户达到客户效果，提醒去停掉广告。客户需要的留言今天未达到等等通知。


4.原来页面统计数据显示非常乱，一次性字段显示过多（精简），改为鼠标经过显示 。

5.替换添加填入ID，用搜索选择替换

6.系统查询、添加、列表操作、按钮统一位置，形象。

7.每条数据不超出2行，多出用鼠标经过显示，或点击看详情


8.简化操作按钮，系统全选反选改为一个按钮，搜索框可以输入多个值。


图片太多，分第二篇编写。

Scrum是敏捷过程中比较著名的一个过程框架，被很多团队采用。

Scrum使用迭代的开发方式，每一次迭代中，都会经历一个“计划->实施->验证->反思”的过程。这是一个开发过程，同时也是一个对项目的认识过程，这样的设计其实也是遵循了哲学的认知论.

何谓Backlog？

本文所说的Backlog是Scrum中的一个专用名词，大约意思是待办的工作事项。

那它是用来干什么的呢？

Backlog里面放的是需要实现的所有任务，包括功能性的和非功能性的任务，换句话说，就是咱们已经把客户的需求提炼出来并且已经完成了设计的部分，现在这些已经完成设计的用户需求被放在一个地方，持续添加新的进来并且随时可以分配出去进行开发，这个地方就叫做Backlog。

知道它是干什么了，那你知道为什么我们需要Backlog吗，不就是一个地方可以放需要去完成的任务吗？有那么重要吗？

首先，是的，它很重要。

怎么个重要法呢？

  1. 首先从Scrum的过程看，我们可以发现Backlog是其起源，俗话说，好的开始是成功的一半，其实Backlog也是同样的一个道理，因为它为敏捷开发的成功开了一个好头，有了Backlog，我们就随时可以知道我们需要做什么。
  1. 当然知道要做什么还不够，因为我们是在做产品，而不是只做一个功能，要做的东西太多了，就有可能会乱，最后甚至导致“不”敏捷了。

所以Backlog专门提供了优先级的功能，我们可以根据商业上的需要给每个待做任务设置优先级，而开发时就可以根据优先级来进行开发安排。

不过，设置优先级是一件很重要又很严肃的事情，因为一旦设置了优先级以后，意味着你的产品开发就会按照某个方向上进行了，一旦设置错误，可能会导致很坏的后果，比如某个功能你觉得优先级不高，不看重它，所以一开始不开发，但是竞争对手很快做出来了，然后占领了市场，这个时候你再去更改优先级就有点晚了。

所以对于优先级的设置，我们就会有很多的考虑，

1) 比如根据冒泡法来设置优先级，通过两两比较来确定两个任务的优先级别，然后再去跟第三个比较，再来确定，这样循环下去，得到所有任务的优先级别。

2)
当然冒泡法只是一个设置的优先级的方法，但是得出优先级的方式还是得根据产品的实际情况来决定，比如说优先考虑客户看重的功能，而对于我们自己想出来的优先级就低一点。

3) 再比如，可以根据工作量情况，先完成那些比较容易的，而对于改动很大的放到后面去。

4) 当然，还可以考虑市场投放顺序，根据我们自己想让客户看到的功能的顺序去决定优先级别，毕竟敏捷里是要定期交付给客户Build的。

所以Backlog里优先级的设置是一件相当重要的事情，只有正确的优先级，正确的开发与交付次序才有可能得到最高的产品价值。

3.
除了优先级外，还有一个设置也是非常重要的，就是对于每个任务，你需要做工作量预估，预估什么呢，预估该任务开发完成所需的时间和人力等，敏捷里把这个预估叫做Story
Point，故事点。

故事点这个概念现在争议很多，究竟以怎么样的方式来预估工作量呢？

（1） 有人说用小时，但是我们知道能力强的人跟能力弱的人所用的小时数必然是两样的，所以通过小时来得到故事点并且进而得到Velocity数据是不正确的。

（2） 也有人说按照困难度，但是困难度只能比较每个迭代中完成功能的困难程度，而无法去预判开发的速率趋势。

（3）
也有人说，与其花时间讨论这些，还不如直接分任务做了，这样才敏捷了。那么这样真的是敏捷吗？这样当然不是敏捷了，敏捷还需要一定的预判与分析，不然就不是敏捷，而叫做无序了。

那究竟何种方式能正确的呢？我是觉得还是按照各个公司的实际情况，比如，

（1）你们公司团队。而如果你们团队水平比较均衡，就可以时间，因为水平差不多，对于任何一个功能完成的时间是差不多的。

（2）当然，如果你们公司水平相差比较多，这个时候就可以用困难度了，就像跳水比赛一样，有很多标准的困难度。

假设我们现在已经选好了适合我们的方式，那怎么才能正确地得到这个故事点数的数值呢？

既然这个是估值，那我们就需要评估，谁来参与评估呢？答案是有直接负责这些功能的团队来负责估值，在估值中水平高的人和水平低的人需要进行一些讨论，在确定这个功能的数值。

而对于已经讨论产生的数值，开发人员就得承诺在讨论出来的时间内完成，因为既然是自己讨论出来的，当然能够按时完成，不然就太没面子了，而Backlog恰恰通过这个故事点估值来让大家产生按时按量完成的动力，所以很多时间自愿加班就变得很正常。

当然自愿加班是对估值的一种损害，所以下一次的估值需要对这种损害进行修复，也就是需要对之后的估值多更加仔细的考虑。

通过这种估值以及其不断修复而得到速率分析与预判是相对比较正确的。

介绍了上面三个Backlog的重要性，大家应该能感觉到在敏捷中，Backlog的确是非常重要的一个概念。下面就来具体介绍一下Backlog的几个分类：

由于不同的公司、不同的专家对Backlog的分类总是有点区别，所以我们就以业界最知名的敏捷开发工具TechExcel
DevSuite中的Backlog来举例子吧，

在DevSuite中， 你可以自定义把Backlog被分成几类， 如果按照最大分法的话，我们可以分成三类，一类叫做Product
Backlog，第二类称为Release Backlog，最后一类名为Sprint
Backlog，当然很多其它主流的分类只有第一种和第三种的分类，不过由于DevSuite这个是可以自定义让你自己根据实际需要启用几类的，所以今天还是以DevSuite的方式为准。

对于这三类分法，下面来解释一下：

  1. Product Backlog (产品待办事项)是条目化/量化的用户需求，它将需求文档中需要实际开发的需求条目化地表达出来。

在这个Backlog里，存放着所有已经设计完成需要完成的用户需求，当然只是需要完成，不需要指定时间与负责人，只要分门别类就行了，未来会通过产品地不同版本来一一去实现，就像微软的Windows系列那样，也许微软早就已经设计好Windows
2020的功能了，只是现在还不去开发，只是先放在Product Backlog里罢了。

另外，这个Backlog还可以保存之前准备做但是又被取消或者延迟的一些用户需求等等。

  1. Release Backlog是本次发布需要完成的任务

这里所谓的Release，是指一次大的发布，比如说微软的Windows
8发布。每次发布，我们必然有大量任务需要去完成，而这些任务，即使在敏捷中，也是会事先选择好这次发布需要完成哪些的，当然中间有变更，敏捷还是很欢迎的，但是我相信大部分应该没啥变化。

所以Release Backlog就保存了所有这个发布需要完成的工作，所以这个就意义重大。而且跟分配任务相关的估值、优先级的设置也是在这个地方完成的。

  1. Sprint Backlog是本次迭代需要完成的任务

Sprint Backlog是开发过程用得最多的Backlog，因为每次Release会建立大量的Sprint，而每个Sprint都有一个Sprint
Backlog。

在Release
Backlog中已经设置好了Story的优先级与故事点数，所以根据这两个的值，我们就会通过分解生成更多小的任务的方式去分配到当前Sprint中去完成，开发组长只需要在Sprint
Backlog中将任务根据员工的技术水平与可用时间进行合理分配就行了。

当分配的小任务无法在当前Sprint中完成的时候，可以根据需要在下个Sprint分配任务时分配到该Sprint中继续完成，当然估值方面就需要下次注意调整了。

名词解释：

Sprint：每一次迭代称为一个Sprint。

Backlog：其实就是需求列表。

SM：Scrum Master，Scrum过程的管理者。

PO：Product Owner，需求他说了算。

TEAM：架构师、开发人员、测试人员等。

Chicken：其他相关的人，如老总、客户。 ^_^

故事点：一个相对独立的功能点。

度量：在过程中的一些度量值。如当前系统的BUG数。

事件：过程中出现的一切事件。如小王今天早上在大家在全身心投入站会时时，放了一个屁……

角色

Scrum中只有三类角色：SM、PO、Team。

  1. 1
  2. ...
  3. 7
  4. 8
  5. 9
  6. 10
  7. 11