最新 | 最热门 | 最高评价

+0  高效团队的 CheckList

Tag: 未分类
hizhou 发于 2016年11月24日 11:11 | 点击: 1723 | 展开摘要
http://www.infoq.com/cn/news/2010/03/most-effective-team-structure

团队的结构是否强调自身的长处,支撑短处,而且支持、激励团队成员?团队某个成员的弱点应该可以被其他成员的优势所补足。

团队结构是否将必须同时属于两个团队的人员数目降到最低(而且避免有人同时属于三个团队)?试图同时着手多个并行项目、或是多个任务,都会损害进度。

团队结构是否能将团队保持在一起的时间延至最长?应该更倾向于让成员能够在长期内保持在

查看全文: http://www.udpwork.com/item/15941.html

+0  系统边界如何定义

Tag: 未分类
hizhou 发于 2016年11月23日 14:17 | 点击: 1615 | 展开摘要
主要是参考文献。

一、参考 wiki 关于系统的定义中对边界的定义

https://en.wikipedia.org/wiki/System

系统理论将世界视为一个相互关联的零件的复杂系统。 一个系统通过定义其边界来定义; 这意味着选择哪些实体在系统内部并且哪些是环境的外部。 可以对系统进行简化的表示(模型),以便理解它并预测或影响其未来的行为。 这些模型可以定义系统的结构和行为。

Systems theory views the world as a complex

查看全文: http://www.udpwork.com/item/15939.html

+0  Template Method Pattern(模版方法模式)

Tag: Programming
hizhou 发于 2013年09月25日 14:23 | 点击: 1123 | 展开摘要
在面向对象开发过程中,通常我们会遇到这样的一个问题:我们知道一个算法所需的关键步骤,并确定了这些步骤的执行顺序,但是某些更细节步骤的具体实现是未知的,或者说某些步骤的实现与具体的环境相关。

在这种情况下,在一个方法中定义一个的算法的骨架,而将一些步骤的实现延迟到子类中,我们称这个方法为:模版方法。

模式结构

抽象类(AbstractClass):定义抽象的原始操作(primitive operation),具体的子类将重定义它们以实现一个算法;实现一个模板方法,在其中定

查看全文: http://www.udpwork.com/item/10745.html

+0  UML中的依赖关系和关联关系

Tag: Programming
hizhou 发于 2013年09月23日 15:38 | 点击: 1077 | 展开摘要
在 UML 中,依赖关系(dependency)和关联关系(association)都是类之间的横向关系,较难区分,所以我在这里做些整理,以便更好的阅读 UML 类图。

依赖关系(dependency)

阐述:

可以简单的理解,就是一个类 A 使用到了另一个类 B,而这种使用关系是具有偶然性的、临时性的、非常弱的,但是 B 类的变化会影响到 A;比如某人要过河,需要借用一条船,此时人与船之间的关系就是依赖;依赖关系总是单向的。

表现:

表现在代码层面,如类 B 作为

查看全文: http://www.udpwork.com/item/10731.html

+0  是 WordPress 让 PHP 更流行了,而不是框架

Tag: PHP
hizhou 发于 2013年08月01日 22:28 | 点击: 1638 | 展开摘要
Tiobe Index(编程语言世界排名指数),是一个显示各种编程语言的相对流行趋势的排名,开始于 2001 年,每个月更新一次。它将很多站点的搜索结果计算在内,以得到统计数据。这些站点包括:Google,Blogger,Wikipedia,YouTube,Baidu,Yahoo,Bing,Amazon 等。

PHP 在 Tiobe 上排名一直靠前,但最近它的排名更靠前了,2012 年是第7,现在是第5。人们可能将此归因为去年年底 Zend Framework 2 的发布,

查看全文: http://www.udpwork.com/item/10714.html

+0  编程要不要美

Tag: PHP
hizhou 发于 2013年07月27日 15:28 | 点击: 934 | 展开摘要
在《GAE 添加 PHP 支持引发的一波讨论》中,有篇挺 PHP 的文章,第四部分,作者提出了:编程不一定要美(因为 PHP 被诟病的原因之一就是很多 PHP 代码是丑陋的)。

先翻译出来,再说说我的观点。

翻译开始 {

多年前,我开始看到人们赞美 RoR(Ruby On Rails),相对于使用 Java 或 PHP 这些语言,他们认为 RoR 是 Web 应用开发的最佳选择。

我看到在 RoR 创建者 David Heinemeier Hansson 的一些言论中

查看全文: http://www.udpwork.com/item/10715.html

+0  Composer 的结构

Tag: PHP
hizhou 发于 2013年07月07日 15:47 | 点击: 11517 | 展开摘要
这片文章是 composer.json 中各个字段的说明书。

一、Root Package(根目录包)

根目录包就是在你的项目的根目录由 composer.json 定义的包。主要就是由 composer.json 来定义你的项目的依赖。

某些字段只能在根目录包的中使用,比如 config 字段,只有根目录包能定义自己的配置。依赖包中的 config 字段是被忽略的。所以 config 字段是 root-only 的。

如果你克隆了其中一个依赖包并在上面工作,那么这个

查看全文: http://www.udpwork.com/item/10716.html

+0  Composer 的库

Tag: PHP
hizhou 发于 2013年07月06日 21:38 | 点击: 1001 | 展开摘要
继《Composer 基本用法》,接着翻译官方文档的下一部分:Composer 的库。之所以想到翻译这部分,是因为,之前我的项目是基于 Symfony 2 框架,是框架在用 Composer,而不是我,现在我在准备自己的项目,我要用 Composer,得知道的更多。

适合阅读对象:

1、了解什么是 Composer(不了解的看这里:《Composer (作曲家),PHP 的依赖管理器》)

2、想了解如何让你的包能通过 Composer 安装

3、想了解 Compose

查看全文: http://www.udpwork.com/item/10717.html

+0  Google AppEngine 适合托管 PHP 应用么?

Tag: PHP
hizhou 发于 2013年07月04日 22:42 | 点击: 1267 | 展开摘要
翻译一段 GAE 托管 PHP 应用的利弊分析文章。以下为内容。

 

你也许想知道,AppEngine 是否真的对 PHP 网站支持的很好。

现在,GAE 将官方的 PHP-5.4 定制和整合到 Google 云平台。很多常用的扩展已经编译进去,当然,不是所有。

这当然是一个有约束的环境,所以你别指望所有 PHP 特性都能用上。GAE 环境和常规环境会存在一些差异,有利的和不利的都有。

还没有人把真正的使用报告给出来,差异肯定比我们想象的要多,我们可以先从

查看全文: http://www.udpwork.com/item/10718.html

+0  GAE 添加 PHP 支持引发的一波讨论

Tag: PHP
hizhou 发于 2013年07月03日 23:12 | 点击: 646 | 展开摘要
5月份的 Google I/O 大会,Google 宣布 GAE(Google App Engine)将支持 PHP。

这一支持,引发了一波针对 PHP 的讨论,有些唱衰 PHP 的人就说是 Google 挽救了 PHP,不然 PHP 就快挂了;有些看了唱衰的文章的人觉得看不下去了,于是也长篇大论地开始反驳。

唱衰的文章有篇国内已经翻译了,原文叫《Google Pries Another Nail From PHP’s Coffin》,在 CSDN 上被翻译为《拯救行将就

查看全文: http://www.udpwork.com/item/10719.html

+0  信息的组织

Tag: Production
hizhou 发于 2013年06月18日 21:53 | 点击: 555 | 展开摘要
本文是《锦绣蓝图》第三章的阅读笔记,主要回答:如何组织信息、如何引导访问者。我按原文也记录了 9 部分,以人们访问网页会问的问题,引出前 4 部分,阐述信息组织方案的作用,再引出后 5 部分。后 5 部分的实现是前 4 部分的基础。

人们访问网站主要3个原因:

寻找东西;

完成任务;

消磨会时间;

访问一个页面时,人们会问自己以下4个问题:

我在正确的位置上么?

网站上有我要找的东西么?

网站上还有没有更好的东西?(如果这个我不满意)

我现在该做什么?



查看全文: http://www.udpwork.com/item/10720.html

+0  《锦绣蓝图》阅读笔记

Tag: Production
hizhou 发于 2013年05月28日 23:15 | 点击: 556 | 展开摘要
这篇笔记关注信息架构的三个基本任务,主要就是书本的第二章内容。全书的结构是循序渐进讨论信息架构的首要目的:实现可查找性(findability),而不是按产品设计的步骤,所以先关注基本任务这个章节。

 

信息架构通常是一个分布式的任务。主要涉及领域:

1、你的用户是谁(了解你的用户群体)

2、为什么企业/有人需要你建立一个网站(了解企业/项目发起人的想法)

3、你有哪些材料(了解技术)

一、你的用户是谁

要充分了解典型用户,并把有关知识应用到设计决策中

查看全文: http://www.udpwork.com/item/10721.html
|<<<12>>>| 一共2页, 15条记录