• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp

mvn package
mvn eclipse:eclipse

<dependency>
            <groupId>jwebunit</groupId>
            <artifactId>jwebunit</artifactId>
            <version>1.2</version>
            <scope>test</scope>
            <exclusions>
                <exclusion>
                    <groupId>rhino</groupId>
                    <artifactId>js</artifactId>
                </exclusion>
            </exclusions>
        </dependency>

mvn eclipse:eclipse -DdownloadSources=true

mvn -Declipse.workspace=<path-to-eclipse-workspace> eclipse:add-maven-repo

src/main/java
src/main/resource
src/test/java

mvn test
mvn package
mvn install

mvn install:install-file -Dfile=X:/path/mail-1.3.jar -DartifactId=javamail -Dversion=1.3.1 -Dpackaging=jar -DgroupId=javamail

<repository>
      <id>companyName</id>
      <url>http:// ${ip}/maven</url>
</repository>

mvn test
mvn package
mvn install

<project>
        [...]
        <distributionManagement>
            <repository>
                <id>proficio-repository</id>
                <name>Proficio Repository</name>
                <url>file://${basedir}/target/deploy</url>
            </repository>
        </distributionManagement>
        [...]
    </project>

<project>
        [...]
        <distributionManagement>
            <repository>
                <id>proficio-repository</id>
                <name>Proficio Repository</name>
                <url>scp://sshserver.yourcompany.com/deploy</url>
            </repository>
            </distributionManagement>
        [...]
    </project>

   <project>
    [...]
    <distributionManagement>
        <repository>
            <id>proficio-repository</id>
            <name>Proficio Repository</name>
            <url>sftp://ftpserver.yourcompany.com/deploy</url>
        </repository>
    </distributionManagement>
    [...]
    </project>

 <project>
        [...]
        <distributionManagement>
            <repository>
                <id>proficio-repository</id>
                <name>Proficio Repository</name>
                <url>scpexe://sshserver.yourcompany.com/deploy</url>
            </repository>
        </distributionManagement>
        <build>
            <extensions>
                <extension>
                    <groupId>org.apache.maven.wagon</groupId>
                    <artifactId>wagon-ssh-external</artifactId>
                    <version>1.0-alpha-6</version>
                </extension>
            </extensions>
        </build>
        [...]
    </project>

<project>
        [...]
        <distributionManagement>
        <repository>
            <id>proficio-repository</id>
            <name>Proficio Repository</name>
            <url>ftp://ftpserver.yourcompany.com/deploy</url>
        </repository>
        </distributionManagement>
        <build>
            <extensions>
                <extension>
                <groupId>org.apache.maven.wagon</groupId>
                <artifactId>wagon-ftp</artifactId>
                <version>1.0-alpha-6</version>
                </extension>
            </extensions>
        </build>
        [...]
    </project>

<mirror>
      <id>emay local</id>
      <mirrorOf>central</mirrorOf>
      <name>emay local artifactory</name>
      <url>http://内部库ip:8081/artifactory/repo</url>
    </mirror>

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

1.Streber背景介绍：
Streber是一个基于WEB的在线项目协调工具，它融合了wiki的思想和项目协作管理机制，成为了一个适用于小型团队的可以贯穿真个项目生命周期的项目协作和管理工具。
Streber的出现的历史并不长，作者为德国人，网名pixtur，其产品原型为05年一个作者的在线office系统，在进行这个在线office系统开发工作当中，作者发现其思路可以很好的成为一个在项目开发的协调组织的工作平台。于是作者对原有产品的不断的修改和完善其在线协作理念，乃至到最后从原有产品中完全剥离出来成为独立的开源项目。
“Streber”在德语中意为是一个具有高度热情和经理旺盛的人，按我们白话说就是一得瑟的人....它是基于PHP开发的项目，目前的最高版本是 0.803，基于php5。同时Sreber是基于GPL开源协议，这点一定要注意，这意味着你如果使用其进行修改和发布也要遵循GPL协议，把你的修改的代码进行开源发布。

图1-1
Streber截图
-----------------------------------------------------------------------------------------------------------------------
2.Streber特点概述：
1.基于wiki的方式
Streber中采用基于wiki的管理方式和语法，采用多人协作的方式进行项目的管理和文档的编写，项目中的任务和文档资源无论创建者是谁，其他人都可以方便的修改和完善，在这种方式下项目人员自由度很高，极大的提高了项目协作的效率，但需要求人员在遵守一定的项目规则下进行项目协作。基于wiki的思想更可以使知识管理与项目紧密的联合起来，不用再为项目搭建一套知识管理系统。
2.简单而灵活项目管理协作系统
Streber类似于jira，也是面向issue的项目协作系统，使用方便，操作简单，系统中常用操作基本元素就是task（也称为issue）和 comment，并且可灵活进行运用，可以作为贯穿项目生命周期中的支持系统，也可以单独作为缺陷跟踪系统，甚至可以单独作为项目知识管理系统使用。
3.label标签分类功能：
Streber中的任务类型可以是一般Task类型，DOC类型，bug类型，idel类型，
feature类型，research类型，refactor类型等等，我们可以通过这些类型对任务进行表示和搜索。
4.全面的角色及其权限分类
Steber中的默认角色按照一般项目类的角色分为项目成员，系统管理员，项目经理，开发人员，方案人员，测试人员，客户，受信客户，以及Guest集中角色，各个角色的默认权限不同，如有特殊情况，管理员可以为每个人定制权限。这些角色是系统自带的，如果要添加自己项目的权限，可以通过直接修改数据库数据实现。
5.邮件通知和RSS支持
在项目中的每个task的辨变更和更新记录都会被详细的记录下来，从更改者的角度，这些在进行变更和任务更新的时候可以选择是否将更新邮件通知此此任务的相关干系人，保证信息的及时同步。 并且任务的相关联系人可以使用RSS的方式对项目的变更和更新记录进行订阅，实现主动获取变更信息的功能。
6.替代sharepoint等项目门户网站功能
我们可以使用Streber代替项目门户的功能，可以将在各个项目中中Contact Info、Baselined Schedule、News元素放在项目主页上，使项目信息沟通全面通畅。Streber支持，英，德，法，西班牙，意大利等12种语言的系统界面，可惜的是目前还不支持中文的系统界面。
-----------------------------------------------------------------------------------------------------------------------

3.Streber应用介绍
3.1安装：
Streber的安装十分简单，简单分为以下几个步骤：
1.环境准备：准备一个Mysql，一个Apache服务器，并从http://www.streber-pm.org/index.php?go=fileDownload&file=6434下载一个Streber的最新版，然后直接copy到htdocs目录下。
2.启动Apache，运行index.php。根据提示填写管理员用户名，密码，数据库地址，用户名，密码。
3.删除安装目录下的install文件夹

3.2应用：
使用过其他项目协作工具的人都会发现Streber的应用操作十分简单，它主模块分为Home，Project，People，Company几个部分，一般在进行项目开发的时候我们只会经常用到项目模块中的功能。

3.2.1 Home：
在Home模块我们可以管理与自己相关的项目，任务，为添加评论，查看最近的任务更新列表，书签，和effort（人工管理）
3.2.2 Project:
Projec是我们在进行项目协作的时候最为经常使用的模块，也是Streber系统的核心模块。在Project中我们可以进行项目的定义，项目中任务的分配，项目相关文档的撰写，项目后期缺陷的跟踪调试，项目进度控制，项目任务的变更和进度更新等等，所有项目的行为活动都是在这里进行定义。每个Project中针对项目的管理又细分为 Task，Topic，Milestone，Version，Files，Effors，Chages几个元素进行管理，为了便于理解，我们可以把所有这些元素都看为不同类型的task。当我们建立Project的时候，我们可以根据自己的需要设定是否保留这些元素。
Task：Streber中所有项目活动Streber中所有项目活动都是基于Task，不论这个Task可能是个开发任务，或是个Bug，又或者是一个说明文档，设计文档，可以说，它是类似JIRA中的 issue驱动，在Streber中的Task驱动。每个Task都有一个唯一的Streber中所有项目活动都是基于Task，不论这个Task可能是个开发任务，或是个Bug，又或者是一个说明文档，设计文档，可以说，它是类似JIRA中的issue驱动，在Streber中的Task驱动。每个 Task都有一个唯一的TaskID，通过这个TaskID会对应一个唯一的项目URL，这样，我们可以使用这个TaskID作为每次代码check-in的说明，说明此次check-in的目的，就不用写太多的commit日志了。Task的属性分为一下几种：
1.Task属性： Task中可以指定任务的Milestone（指定的为了实现某个Milestone所做的任务），任务的优先级，任务分配人员，目前的状态(new,open,block,done,approved,closed)，任务完成节点（如果本次无法完成，设定为下个版完成，如果本次可以完成，需要设定在哪个milestone完成的，或者可以不做设定），任务完成类型（如果是task则类型为done，如果为bug则类型为fixed，其他的根据任务类型依此类推）。
2.Task时间管理：预计正常完成时长，最坏情况下的完成时长（正常时间+buffertime），任务起始时间，任务结束时间。
3.Task描述:使用wiki格式。
4.Task显示：任务的缩写（显示在导航栏的名称），任务id（可根据任务所需自由设定，这个是由项目组设定的，比如ex-01）,任务的标签，供以后任务分类和搜索使用，其中包括Bug，Feature，Enhancement，Refactor，Research，Idea，Orgnaize，Wiki，Docu。
Topic：主题信息管理,Topic在项目中一般起到发布主题类的信息，可以是项目说明文档，项目会议记录，项目需求变更计划，项目内部新闻等等文档类信息，同样可作为项目知识管理的功能使用，比如代码规范，项目开发规范。
Milestone：里程碑计划管理，项目的里程碑管理，同Task设置类似，Milestone中可以设置负责人，时间管理，任务描述，显示描述，Milestone设置后可以与每个task进行关联，上面已经提到，每个task的目标都是要针对于某个具体的Milestone的，所以把Milestone看做是一个大的 Task，由无数小的task的集合形成。Streber的思想还是比较严谨的开发模式，具体的使用还是看各个项目了。
Version：版本计划管理,里面元素设定与Milestone和Task类似，我们在项目中可以把Version看做Milestone的父类，把Milestone看做Task的父类。在项目周期前期，按照这种方式，先设定Version，再设定这个Version中的Milestone，在设定每一个具体的 Task，给其指定所属的Milestone。
File：项目文件管理，与此项目有关的资源文件可以同一放在这里进行管理，与一般的在线系统类似，Streber的理念就是使平台达到能将项目周期活动都集中在此的目的，所以此功能虽然简单，但是还是相当有用的，我们可以把项目工具，框架，各类前期说明书等等文件都在此进行资源共享，统一管理。具体好处就不多说了。
Efforts：字面上的意思是人工管理，感觉其实就是在在项目任务中计算人员工作量的工具，在项目开发和人工绩效考核的时候应该有一定作用，同时Streber提供统计Efforts功能，但似乎这个功能还未完全完善，建议可以先不用使用。
Changes：变更记录，所有任务和文档的内容更新和状态更新以及评论添加都会在这里可以进行查看详细的信息记录


3.2.3 People: 人员管理 ，在这里设置项目人员信息，人员类型，默认的人员类型系统管理员，项目经理，开发人员，方案人员，测试人员，客户等项目基本干系人。我们在这里对项目中所有干系人进行管理，并设定相关人员所属的公司。个人认为在项目中，无论大小，上述的这些角色一定要尽量全员参与到系统的使用中来。不同的干系人具有不同的人员权限的设置，系统在初次安装之后只有管理员有用最高权限。权限设置比较简单，只有针对项目，人员，登陆，等相关权限，但对于一般的小型项目足够使用了。

3.2.4 Companies:公司管理 在这里可设置公司信息，公司类型，公司类型可为
一般客户，高活跃度客户，供应商，各做伙伴。在建立项目和建立人员的时候都可以设定所属公司。
3.2.5 Search:搜索功能，在所搜的关键字前加入‘！’可直接跳到最佳结果页面中。
----------------------------------------------------------------------------------------------
4.Streber在项目中的实践：
我们基本上了解了Streber的功能，可以看出系统使用相对大型商业软件要简单的多，相对缺少了很多纷繁复杂的工作流程，细化流程和统计功能。但是对于中小型项目来说，Streber已经抓住了项目中的关键要素，只要使用方法得当，将项目管理思想很好的融合到工具中，Streber可以使一般项目的质量和开发过程得到一个很大层次的以高。下面就我在项目管理过程中的经验与结合Streber的一些实践方法分享出来，希望大家能提出宝贵意见并且能将自己在管理过程中的经验或使用工具的经验分享出来。

4.1 建立新项目
建立新项目的时候，注意项目描述的重要性，项目描述是显示在项目首页最醒目的地方，所有的项目干系人每次进入项目的时候都会看到，在项目描述中将项目的目标和意义写好，稍微夸大也是允许的，要让让开发人员认识到他们所做的事情的重要程度，做到信息对称，我们的项目团队对项目的成功有共同的认识，使我们项目顺利完成的第一步。在项目关闭后，我们将项目总结再补充到项目描述之中，整个项目周期完成。

4.2 建立干系人管理和沟通机制
包括客户，公司领导，开发人员，市场人员等和项目相关的一切人员，都在系统中设立相应的账号使各方人员均能参与其中。我们在其中一个项目中为客户开放阅读（RSS订阅）与编辑权限（编辑权限看情况而定），可以让其参与其中，增加客户的团队归属感，使其了解团队的各个方面，包括项目进度汇报，各类文档资料，潜在困难，资源需求，使其主动帮助项目向更好的方式发展。
4.3 建立项目知识库
建立知识库的好处众所周知，知识库已经越来越成为现在软件项目过程中的一个重要组成部分。我们使用Project中的
Topic功能实现项目中的知识库的功能。我们在知识库中记录项目的代码规范，测试用户编写，项目工具经验，页面设计规范，文档专业规范等一般基础性知识点，同时在一些项目中，可以直接在知识库中进行项目说明书，开发设计文档，项目风险列表等开发类文档。使用 Project中的Folder功能可以进行文档的分级显示和管理。

4.4沟通管理
Streber本身就是一个很好的沟通管理工具，我们在项目中主要使用其作为一个被动信息共享平台。开发人员使用Topic功能进行针对项目周报和月报的撰写，具体方法可以让汇报与上面的知识管理使用不同的Folder，在汇报的folder中为每一个开发人员（使用姓名或员工编号）建立一个周汇报的 topic和一个月报的topic。客户，公司领导和项目其他相关人员可以通过邮件或者Streber的RSS功能定期或手动收取这些报告，以了解项目的进度。同时项目经理和高层领导可以在这些汇报中批示自己的意见建议，或鼓励或表扬，对于开发人员的开发热情是一种激励。
在Streber中，每个任务都有一个TaskID的唯一标识，我们利用这个ID与其他的项目协作工具关联起来，例如我们在每日编译后在Check in到代码库的时候可以将每人负责的的Taskid作为comment提交到代码库。这样每次的提交都会有一个具体的taskid任务与之对应，以后有问题可以根据taskid对代码版本进行针对性的复查，将版本与代码关联统一管理起来。

4.5任务流程和任务设置
任务分配和协作无疑是使用Streber最大的目的之一，在我们的项目实施周期，我们无论采用何种软件开发方式，最终都离不开以下几步： 计划任务（全体项目组人员）-》形成项目阶段界定（milestone，项目组全体成员）-》分析安排任务（全员讨论，项目助理在Project中登记任务）-》任务实施（项目组员打开任务，实施更新进度）-》完成任务，项目经理审核-》审核通过，项目助理关闭此任务。注意在进行任务分配和登记的时候注意任务一定是具体的，可以验证的。 Strber中的任务具有new，open，done，apprived，closed几个状态，我们对应任务在上述不同阶段使用不同的状态进行标示，同时任务在分配登记的信息只是任务的一些基本信息，描述，优先级，状态，类型（Label，新的开发任务可以为task或feather，如果是），至于任务的时间就需要和每个被分配人员商议讨论，最好由本人进行估算，之后再进行登记。
在项目实施过程中，注意要让团队成员养成每日对任务情况进行汇报的习惯，这个习惯如同每日编译和每日check in一样重要，目的是事project中的任务进度一定要反映最近的情况。具体的汇报方式可以使用评论的方式，每个成员对本人每日的工作在相应任务下面以 add comment(评论)方式加入简短的总结，并根据自己的任务完成情况更新项目情况，包括项目完成进度百分比，项目状态，如果遇到任务变更或突发实践也可以直接更改任务的周期，并最好在comment中说明一下。在任务完成并审核后，登记人员对任务进行关闭，关闭的时候需要选择此任务的关系原因，如果是新功能（feather）的task，直接选择done即可，如果是bug类型的任务，则需要选择fixed，其他类型可根据任务的状态和类型不同选择相应的关系状态。

在缺陷跟踪方面，Streber中对缺陷的跟踪方式与任务一样，事实上这里的缺陷就是一种类型为BUG的任务，其发布方式和流程与其他任务没有太大区别，只需要注意task的类型，label的类型等设置即可。Tester（测试）在进行缺陷登记的时候，注意是否写清了Bug的重现步骤，并且保证所有的缺陷都是有登记的人进行验证后进行关闭。我们在登记缺陷的时候，也要写清楚这个缺陷的优先级，开发人员一定要保证在开发新功能前把所有严重的缺陷解决掉再开始新任务。

-----------------------------------------------------------------------------------------------
5.不适合使用Streber的情况：
1.Streber官方网站上表明，本系统只适合1-40人的小型团队，的确，Streber没有商业软件的自动化流程，也没有其软件的功能细化程度高，但这个描述也有点儿太绝对了，还是要根据项目实际情况和管理体系来确定。
2.Streber不是一个缺陷管理工具，它关注与项目的整个生命周期，同样也没有相应的二次开发的API和与CVS，SunVersion之间的插件。
3.Streber不是一个纯wiki系统，不要把它当作WIKI系统使用，它的性能对于项目内部管理来说足够使用了，但是并没有加入太多的性能优化和缓存机制，所以把其当作内容管理系统来做是相当不明智的。
-----------------------------------------------------------------------------------------------
6.使用总结：
在软件过程改进技术不断发展和进步的情况下，很多国内中小型企业的开发规范化和项目管理机制确一直滞留在4，5年前的样子，这样的情况对于企业和雇员的发展都具有很大的弊端。近年来市面上也出了很多项目协作和管理工具，例如有名的JIRA，Xplanner，版本控制工具svn，cvs等等。这些工具各有个的特点，关键使用工具不是目的，目的是要在工具辅助基础使用项目管理思想上最大限度的对项目进行控制，对软件构造过程进行不断持续的优化和改造，这样才能使软件企业和项目得到良性发展。本文在Streber上也是个大体的说明，strber中包括wiki的使用，任务的转接分派，项目元素的移动，权限的具体设置本文都没详细的进行阐述，我会在以后的相关文章中逐渐进行说明，由于streber的中文文档几乎没有，如果大家有相关的经验技术可以一同进行交流。
-----------------------------------------------------------------------------------------------
附录：WIKI语法初窥
WIKI语法适合进行多人协作文档和版本控制，由于streber基于WIKI的思想和语法进行设计，文档的编写使用都是WIKI的语法，所以本文简单介绍一下WIKI语法核项目中常用的语法，如在使用过程中需要wiki语法的进一步支持，可以到这里http://www.allwiki.com/wiki/Wiki查询。

标题（heading）
== Top Level ==

=== Second Level ===

或者

Top Level
========= <- 3 or more '=' characters

Second Level
------------ <- 3 or more '-' charaters
列表（List）

# Numbered
# Numbered
代码框
[ code from="index.php"]
some more code
[ /code]

Email链接
Send to mailto:zm@streber

表格（Tables）

|Header |Header |
|Cell |Cell |

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

一般而言，代码库的目录结构如下：

       有的时候，也会把release目录命名为tag，之所以按照这样的目录结构来命名是有缘由的，下面是我个人的一些理解，供参考。

       任何一个项目/产品都会经历一个从无到有的过程，在这个过程中，我们会使用Trunk这个目录，当产品达到发版要求时，我们会将发版那一个点的代码做一个Tag,放到release/tag目录（由于项目不同，其目录结构也会有所差异），这是一个静态的点。比如，当GCL2008发版时，我们会做一个Tag,以捕捉625的环境一部分（这里只包括源码，最好打版本的脚本也能够在这里），并没有开发环境（比如Dephi）。

       当同时需要开发两个版本或对源码的改写不是那么确定时，我们就需要做一个Tag到Branch，其实这个Branch的作用与Trunk类似，也是一个动态，代码会在这里不断演进。比如GSP的升级，因为有很多不确定因素，所以我们需要做一个Branch,以防止不确定性问题的发生对项目造成的影响，如果没有发生问题，我们还可以将其合并到主干（Trunk）版本上。

       大家可能认为Branch、Tag是一样的，最容易理解就是Tag是一个静态的过程，而Branch是一个动态的过程，代码是一个不断演进的过程。

       对于配置管理员而言可以解决一下几个问题：

1、 版本发布环境一部分的备份（这里只针对源代码和Build脚本）；

2、 对于后期的用户反馈以及补丁制作提供了有力支持（Branch）；

以上我对配置库目录结构进行了解析（在这里并没有包含版本管理的思想），下面我就对SVN的版本管理做一个简单的介绍，利用Log日志，我们可以轻松的记录下什么时间发布了什么样的版本，这个信息对于补丁的管理是十分有好处的。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

我最早接触QA是去年在一家大型制造型企业实习的时候，在这种企业中有两类人最NiuBility，一种是保安，搞的和特种部队似的，一种就是QA人员，相当于现在的城管，非常的威风。
        经过一段时间的了解发现这个公司非常的重视的QA，当时实行的是全面质量管理，QA具有非常大的权力，可以随时随地对各级经理的工作进行审查。进一步了解发现其实QA的作用其实是非常的大的，我有大量的一手资料表明实行全面质量管理和引入QA后，公司产品的质量确实有很大的提升，QA在日常工作确实可以发现很多不符合流程的东西，减少很多不必要的损失。总之QA给我留下的印象是蛮好的。
    最后在一家IT研发企业工作后，也接触了点CMMI/QA工作，开始我对QA的态度是非常的积极的，但最后发现引入QA后，我们的软件产品质量并没有提升，而且我们做了大量的QA工作却并没有收到预期的效果，我反思后觉得有以下原因困扰我们实行QA的地方：
        一个是按CMMI的说法，QA主要是检查过程的执行是否符合要求，那么并不能直接作用于产品，只能通过保证过程来间接的保证质量，对于制造型企业，很多东西是依赖于机器化的流水线作业，而对于软件企业来说很多东西很难规程化，人的因素总是琢磨不定的，所以即使过程执行的很完美，但过程所产生的东西不见得同样是完美的。
       还有一个变通的做法是，弱化对过程的检查，强化对工作产品的检查，比如对设计 编码 测试等各方面做深入的走查，那么这就要对QA人员的要求非常的高，要求对软件开发的各个环节有很深的认识与经验，但是公司也不大可能会把有这种能力的人放到QA的岗位，很多公司的做法是把新手推到QA的岗位，所以QA检查难免会走形式化的路线。
       那么到底如何保证的质量呢？我的一点不成熟的看法是主要由项目经理来保证，理由是做一个项目其实是项目经理对各个环节最了解，也具有一定的管控能力，但这又涉及到一个客观的问题，谁也不知道这个项目经理是不是有很强的自我纠错的能力，QA的理念其实也是想借助于独立的第三方来做客观的审查，但是，我还是认为给予项目经理足够的信任，让他来对质量负责更加实际点。

• 搜狐网站诚聘Java、PHP和C++工程师
• 北京: 千橡集团暨校内网诚聘软件研发工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师

• 北京: 千橡集团暨校内网诚聘软件研发工程师
• 搜狐网站诚聘Java、PHP和C++工程师