易栈网-膘叔

最近重操旧业，看起了zend framework，如今的1.9x与以前不一样了。所以，把ZF的quick start逐步翻译一下，权当复习和温故了。

原文地址：http://framework.zend.com/docs/quickstart/create-a-model-and-database-table

ZF & MVC Introduction

Zend Framework

Zend Framework is an open source, object oriented web application framework for PHP 5. ZF is often called a 'component library', because it has many loosely coupled components that you can use more or less independently. But Zend Framework also provides an advanced Model-View-Controller (MVC) implementation that can be used to establish a basic structure for your ZF applications. A full list of Zend Framework components along with short descriptions may be found in the components overview. This QuickStart will introduce you to some of ZF's most commonly used components, including Zend_Controller, Zend_Layout, Zend_Config, Zend_Db, Zend_Db_Table, Zend_Registry, along with a few view helpers.

Using these components, we will build a simple database-driven guest book application within minutes. The complete source code for this application is available in the following archives:

zend framework 介绍

ZF是一个开源且面向对象的，支持PHP5的WEB应用框架。ZF通常被叫做“组件库”，因为他拥有很多松耦合的组件，因此你可以在应用中或多或少的独立使用它们。但ZF更多的是为你的ZF应用提供了一个高级的MVC架构【？？翻译不来了】所有的ZF组件列表，你可以从 组件预览 页进行查看。而这个QuickStart会给你的ZF最通常使用的组件进行介绍，如Zend_Controller,Zend_layout,Zend_Config,Zend_Db,Zend_Db_table,Zend_Registry,以及一些视图助手【这个应该是讲View的，但不知道怎么翻译好。现在终于明白那些翻译书的朋友们的痛苦之处了。明知道啥意思就是说不出口，还是词汇量少啊】

Model-View-Controller

So what exactly is this MVC pattern everyone keeps talking about, and why should you care? MVC is much more than just a three-letter acronym (TLA) that you can whip out anytime you want to sound smart; it has become something of a standard in the design of modern web applications. And for good reason. Most web application code falls under one of the following three categories: presentation, business logic, and data access. The MVC pattern models this separation of concerns well. The end result is that your presentation code can be consolidated in one part of your application with your business logic in another and your data access code in yet another. Many developers have found this well-defined separation indispensable for keeping their code organized, especially when more than one developer is working on the same application.

MVC

那么我们就来讲讲什么是MVC了以及你对于MVC来说，最关心的是什么。MVC虽然只是三个单词的开始每个字母组成的新词，然而他已经成为了网页程序的标准设计模式了。而且，有充分的理由证明，大多数的网络程序代码都被归于以下三种分类之一：表达方式【？】，商业逻辑 和数据访问层。MVC模式则能够使你们将关注点进行分离。最终你的表示代码只占你的商业逻辑的一小部分，同样数据访问层也是这样。大多数开发人员发觉这能够使得他们保持代码分离并且条理清晰，尤其是在同一项目中有多名开发人员时。

翻译的很迷惘。。。

其实上面的大意无非就是MVC结构使得程序员可以将更多的精力放在业务逻辑上，而不是将大量的精力浪费在表现层和数据访问上。

不过，虽然翻译的很乱，但我还是多少又理解了一点这方面的知识。MVC如今已经被很多人所接受，很多招聘上也都写着，熟悉MVC模式开发。其实，如果真正项目已经按着MVC模式开发的话，那么招聘进去的人，又有多少是同时对于这三个方面进行开发的呢？

Model - View - Controller，在ZF框架中也是很分离的。看框架的 application目录就很清楚了。除了module和config目录外，剩下的就是：controllers,models和views目录了。。由此可见，基本上也分得比较清楚了

国庆的时候，因为备案问题关闭了几个网站，然后就是天天查询我的备案是否下来，今天是12日，刚过丨丨节，再次查询的时候，激动人心的时刻到了。。。



啥也不说了，泪流满面啊

这又是一篇来自于 帕兰映像 的文章：14条最佳JS代码编写技巧，但并非全部，我只复制粘贴了一小部分我所需要了解的，如果需要看全文，还是点上面的链接去他那里看吧。

1、总是使用 ‘var’ ，其实这个真的很重要。如果你一个不小心，你就会遇到变量重名或者无意中就引用了全局变量。
2、使用方括号记法。对于JS的对象，一般我们都是采用 aa.bb.cc来访问的，但其实也可以用aa["bb"]["cc"]来进行访问。

使用”.”号，属性名是硬代码，不能在执行时改变。使用”[ ]“方括号，属性名是一个通过计算属性名而来的字符串。字符串要以是硬代码，也可能是变量，甚至可以是一个调回一个字母串值的函数。 如果一个属性名在执行产生，方括号是必须，如果你有 “value1″, “value2″, 和 “value3″这样的属性，并且想利用变量 i=2来访问
如：MyObject["value"+i] ，你就不能写成：MyObject.value+i
并且在某些服务器端环境（PHP、Struts等）下，Form 表单被附加了 [ ] 号来表示 Form 表单在服务器端必须被当作数组来对待。如此，用”.”号来引用一个包含 [ ] 号的字段将不会执行，因为 [ ] 是引用一个 Javascript 数组的语法。所以，[ ] 号记法是必须的。推荐使用”[ ]“方括号记法是说当其需要时（明显地）总是使用它。当不是严格需要使用它的时候，它是一个私人的偏好和习惯。一个好的经验原则是，使用”.”号记法访问标准的对象属性，使用”[ ]“方括号记法访问由页面定义的对象属性。这样，document["getElementById"]() 是一个完美可行的”[ ]“方括号记法用法，但 document.getElementById() 在语法上是首选，因为 getElementById 是一个 DOM 规范中定义的一个标准文档对象属性。混合使用这两个记法使哪个是标准对象属性，哪个属性名是由上下文所定义的，在代码中显得清晰明了

3、在锚点中使用 “onclick” 替代 “javascript: Pseudo-Protocol” ：如果你想在 <a> 标签中触发Javascript 代码，选择 onclick 而非 JavaScript: pseudo-protocol；使用 onclick 来运行的 Javascript 代码必须返回 ture 或者false（or an expression than evalues to true or false [这句要怎么翻译呢? 我是这样理解的：一个优先性高于true 或 false 的表达式]）来返回标签本身：如果返回 true，则锚点的 href 将被当作一个一般的链接；如果返回 false，则 href 会被忽略。这就是为什么”return false;” 经常被包含在 onclick 所处理代码的尾部。

4、使用一元 ‘+’ 号运算符使类型转向Number：大家都知道“+”是javascript的连接符，但其实他也可以作为转换符来使用，如可以使用”+”号来把数组转换成数字。给变量或者表达式前置一个”+”号将会强制其当作一个数字来处理，而这也将使得数学”+”得以成功应用。

5、避免乱用全局命名空间。一般很少需要全部变量和函数。全局使用将可能导致 Javascript 源文件文档冲突，和代码中止。因此，一个好的做法是在一个全局命名空间内采用函数性的封装。有多个方法可以完成这个任务，有此相对比较复杂。最简单的方法 是创建一个全局对象，并把属性和方法指派给这个对象。但即使这样，命名空间也可以使用 Closures（闭包?） 来创建，并且 Private Member Variables （私有变量?） 也可以伪装于 Javascript中。

6、避免同步的 ‘Ajax’ 调用：当使用”Ajax”请求时，你要么选择异步模式，要么使用同步模式。当浏览器行为可以继续执行，异步模式将请求放在后台执行，同步模式则会等待请求完成后才继续。应该避免同步模式做出的请求。这些请求将会对用户禁用浏览器，直至请求返回。一旦服务器忙，并需要一段时间来完成请求，用户的浏览器（或者 OS）将不能做任何其他的事，直至请求超时。如果你觉得自己的情况需要同步模式，最大的可能是你需要时间来重新想一下你的设计。很少（如果有的话）实际上需要同步模式的 Ajax 请求。

这些，是我所关注的。。。一共有14条，你会关注哪条？

前段时间，我做了一个小记录： 即将进入10W以内，今天终于跨进10W大关

10W其实也算一个坎了。04年左右进来过，但后来停站后就再也没有了。
去年差一点进来，但还是离他而去了。。。

如今，我终于进来了，虽然有点辛苦，但。继续喽

努力。向前冲

今天是11月11日，传说中的丨丨节啊。。

本人是没有机会过了，不过俺的小家伙可以考虑提前过节了。

不知道“丨”念啥吧？

gǔn
上下贯通。
笔画数：1；
部首：丨；

其实，好象以前在看电视的时候，听 说河南有一个村的人都是姓这个的。

光棍节快乐，各位光棍们。

突然发现，原来，博客离10W又进了一点。多少年了。。。终于又要重入10W内了。。

先上个图，预祝一下，等确实定了之后，再来上图。。。



很激动人心的图哦【忘了说了，主域名是指：www.neatstudio.com，neatcn.com还没有到呢。。。】

这个，又是老王的文章，队列，确实还是需要用到的。不过，我倒真没有想过用专业的队列消息数据库等来处理。我最初只是想把一些要队列的信息用SQLITE来处理，一边是往里推，一边是往外拉。拉一条删除一条。等到数据量太大的时候，就清除掉。

老王还是有介绍的，我在PHPRPC群里也听缘起缘灭和廖羽雷他们谈过专业的队列处理，但，我目前做的事情，还是用不了专业的队列处理，所以也就没有放在心上，不过，既然老王有介绍，也可以稍看看【原本我计划做个短信定时发送也就是准备用队列处理的，但最后没做，因为139邮箱里居然有类似功能，NND，抢我饭碗】

Web应用中为什么会需要消息队列？主要原因是由于在高并发环境下，由于来不及同步处理，请求往往会发生堵塞，比如说，大量的insert，update 之类的请求同时到达mysql，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误。通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。在Web2.0的时代，高并发的情况越来越常见，从而使消息 队列有成为居家必备的趋势，相应的也涌现出了很多实现方案，像Twitter以前就使用RabbitMQ实现消息队列服务，现在又转而使用Kestrel来实现消息队列服务，此外还有很多其他的选择，比如说：ActiveMQ，ZeroMQ等。

上述消息队列的软件中，大多为了实现AMQP，STOMP，XMPP之类的协议，变得极其重量级，但在很多Web应用中的实际情况是：我们只是想找到一个缓解高并发请求的解决方案，不需要杂七杂八的功能，一个轻量级的消息队列实现方式才是我们真正需要的。

第一感觉是能不能使用memcached来 实现消息队列？稍加考虑后就会发现它不合适，因为memcached仅仅支持键值方式的操作，没有排序之类的功能，所以如果要用它来实现消息队列，则必须 自己通过某个键来保存数组形式的队列，不过这样的话，在操作队列的时候很容易丢失数据，比如说我们要添加一个消息，则需先取出现有队列，然后把消息保存到 队列尾部，最后保存队列，单纯使用memcached的话，由于我们无法保证整个过程的原子性，所以当处理若干个并发请求时，各个请求间可能会互相覆盖， 丢失数据就在所难免。另外，memcached只是内存键值缓存而已，一旦宕机，数据就消失了。

memcacheq的出现解决了上面的问题，它在memcached的基础上实现了消息队列，以php客户端为例：

消息从尾部入栈：memcache_set
消息从头部出栈：memcache_get

memcacheq依附于memcached之上，所以你可以通过现有的memcached工具来操作它，这无疑是它的一大优势，但它也有一个很大的缺点，那就是memcacheq本身的开发维护似乎并不活跃，如果遇到问题的话，你很可能需要自己动手解决。

目前看来，我更推荐下面这种解决方案，那就是redis，如果不了解，可以参考我以前的文章，表面上看，redis和memcached差不多，也是键值操作，但是redis本身实现了list，相关操作也可以保证是原子的，所以可以很自然的通过list来实现消息队列：

消息从尾部入栈：RPUSH
消息从头部出栈：LPOP

redis本身虽然是一个新项目，但很有朝气，开发维护也很活跃，如果你的下一个Web应用里需要使用轻量级的消息队列，不妨使用它。

此外，还有不少其他的选择可供尝试，比如说MySQL第三方的Q4M引擎，通过扩展SQL语法来操作消息队列，也是一个不错的选择。

套用网络流行语：那些重量级软件实现的不是你要的功能，而只是独在高处不胜寒的寂寞，所以不必迷恋其中，它们只是传说而已。

--EOF--

原文链接：http://hi.baidu.com/thinkinginlamp/blog/item/27a18202578f3d054bfb511f.html

在某人的小说站上线前，答应帮他做点链接
说起小说，突然想起读书时代流传的陋室铭改篇中的一段：小说翻的快，杂志阅的勤，斯是教室，唯吾闲清

自己读书的时候，也是被小说害的呀。天天上课就是看小说，眼睛也是那时候看坏的。。。。

在如今，你闲下来的时候，能干什么？永远播不完的肥皂剧？无聊恶搞的娱乐节目？还是不知所云的走进科学 ？或者在QQ等IM上聊天打屁？

我是用手机上网看看小说，电视几乎不看了，即使要看也是几乎只看discover之类的，上海就是纪实频道了。。。

其它还真没劲。

网上几个看小说的网站：

起点：www.qidian.com

幻剑：www.hjsm.net

爱书吧： www.ishu8.net

在一些PHP的群内，很多人在提问前，都说，我刚学PHP，遇到一点问题，能不能帮我解决，然后刷刷刷的就是几屏代码。
在这种情况下，如果有人有精力有欲望回答他们的问题，估计才真的是奇怪。

网上流传的那篇：《提问的艺术》，估计很多人看过，但有多少人是这样提问的呢？至少我在遇到自己不会的情况下，先找手册，然后问google、百度，最后才问群里或者MSN中的高手们，即使这样，我也很把我遇到的问题和解决的方式说出来，这样，他们在回答的时候，也不会多次尝试。当然或许我一 说出来，他们就知道问题的解决方案了。但你不能保证每个人都是这样的高手吧？

以上都是废话。但还是有点参考价值。以下才是肉戏。

1、IBM的网站，http://www.ibm.com/developerworks

2、ZEND的网站：http://devzone.zend.com/，这里还有为新手写的文章 ：http://devzone.zend.com/tag/PHP101

3、PHP官方网站，如果遇到点问题，发现代码好象没问题，但结果就是不正确，很去搜索一下buglist，或许就是你发现了这个BUG也有可能啊？

4、曾经的PHPE.net，没落的网站

5、喜悦村，也在逐步走向没落，大多数情况下，也是被这种无聊的提问而使得很多人不愿意回答问题吧？

6、phpchina。知名PHP网站，可惜吵架贴远多于知识贴

7、PHP100，在开发工具上提供了一些便 利，还有一些视频可以参考

8、本人的网站，哇哈哈哈。其实本人网站真的只属于一般，但我会努力转贴，当然也不是随便就乱转了。。。技术型的，一般总要看一遍再转的。

其实，你还可以搜索google reader之类的订阅网站，然后以某个关键字为搜索，并订阅这些内容，恐怕也可以让你达到一些效果，但订阅这个玩意，还是以少而精为主，否则，你还是没有精力去一篇篇看，走马观花的，反而会让你错过很多。

一直以来，听到的都是企业文化，难得听到这种所谓的工程师文化。
但在技术型企业，工程师却是占有企业员工大部分的比例，再加上facebook又是非常成功的一个产品，因此，转载一下学习一下。

以下内容来自：http://feedproxy.google.com/~r/hutuworm/~3/YJ-W-K3A4DM/facebook.html

Windows Live 网站有位工程师，参加了 Facebook 组织的 Facebook Seattle Engineering Road Show 活动，回来之后兴奋不已，洋洋洒洒写了一大篇，介绍 Facebook 在不断扩张过程中获得的一些经验：Facebook Seattle Engineering Road Show: Mike Shroepfer on Engineering at Scale at Facebook

大家都会英文，这里不作全文翻译了。值得一提的是 Facebook 自己总结的工程师文化：

1. 快速前进打破陈规（Move Fast and Break Things） - 鼓励员工承担风险，愿意为创新牺牲一些稳定性。工程师厌恶风险往往是公司衰败之始。

2. 小团队办大事（Huge Impact with Small Teams）- 多数功能系统都由一到三位工程师组成的小团队完成。Facebook 每位工程师服务 120 万名用户 v.s. Google 1:190,000 v.s. Amazon 1:96,000 v.s. Microsoft 1:75,000。

3. 大胆创新（Be Bold and Innovative） - 不言自明。

Facebook 连扫地的都算上也只有 900 多名员工，其中工程师只有 230 余人。他们的用户近 3 亿，接近于美国人口总数。他们有 3 万台服务器，存储着 800 亿张图片，每天承受 10 亿次搜索，Memcache 集群每秒操作 5 千万次，每秒下载照片 120 万张......

什么叫海量？这就是海量！

如果没有这样的工程师文化，肯定无法支持海量。