易栈网-膘叔

来自豆瓣，觉得很有用。。。
http://www.douban.com/note/186312698/
出门吃饭的话，可以备一份。看完了就不会被骗了，最起码可以了解行情

甜点微烤黄金小甜饼（南瓜饼）  五分熟神户小牛肉配珍珠甜米饭（牛肉盖浇）  法式卷心菜微甜浓汤（白菜汤）   特调微辣酸甜汁焗猪柳伴长葱 （鱼香肉丝）  木炭火焦烤微煎法国小填鸭 （烤鸭）  蜜糖配白醋焗野猪背脊嫩肉 （糖醋里脊）  意式秘制浓酱鸡肝烩波尔多酒渍青椒 （炒鸡下水）  珍珠蒜蓉微煎白菜（炒大白菜）  墨西哥特辣炖过油精致阿根廷小牛肉配当下时蔬 （水煮牛肉）  芝士浓酱伴意大利面条（热干面）  陈年俄罗斯酸汤加小辣椒煮深海鳕鱼 （酸菜鱼）  墨西哥特辣秘制浓汤杂烩配什锦鲜蔬 （火锅）  鲜香蒜茸浇汁精选各式杂肉 （麻辣烫）  意式蒜蓉微酸浇汁鲜猪嫩柳（凉拌白肉）  爆油葱香干煸五花肉 （回锅肉）  麻辣黑胡椒精腌碎肉炖白玉豆腐（麻婆豆腐）  西安精炖小牛肉浇汁配蒜蓉小面饼/美式上选鲜嫩猪肉汉堡 （肉夹馍）  香油葱花酱汁秘制什锦菜凉拌水晶粉 （凉粉）  四川辣汁煮小牛胃搭顶级小牛血配杂锦时蔬 （毛血旺）  酥炸黑色发酵豆块佐红辣椒蒜汁/小火御制特香脆墨腐块/特级初炸腌制豆乳凝冻浇酱汁/特选酱香豆腐精炸佐  芙蓉蒜醋汁 （油炸臭豆腐）  鲜白玉子配腌制小甜菜黑胡椒浓汤 （榨菜蛋汤）  红椒酱爆微型河鲜配姜茸酸汁 （小龙虾）  特制烟熏蜜汁辣味干鸭片 （酱板鸭）  法式甜酸西红柿片配黄油鸡蛋粒 （番茄炒蛋）  冷翠青葱段配盐渍蒸豆碎 （大葱蘸酱）  意式番茄鸡蛋浓汤浇通心粉 （鸡蛋打卤面）  铁板特煎外十分熟内七分熟碎牛扒佐青椒段洋葱块 （铁板牛肉）  冰镇西贡生虾佐苏格兰威士忌 （醉虾）  高加索焖鸡排香菜碎末配德式浓酱 （全熟/七分熟/五分熟/四分熟/三分熟） （白斩鸡）  百分百原汁澳洲玉子水晶冻 （蒸蛋羹）  泰式翡翠精焖水晶饭 （绿畦香稻粳米饭）  法式闷烧水生蜗牛佐辣椒蒜汁 （辣田螺）  中式炸面包 （油条）  特制甜糯米配日式蜜豆沙及八色澳洲香焙干果（八宝饭）  秘制酱渍猪排泰国香糯米寿司 (肉粽子)  翡翠豆蓉酥皮夹心松饼 (绿豆糕)  黄色毒药鸡尾酒　（雄黄酒）  吮指蛋香超薄碎蔬铁板Q饼夹销魂麦香脆饼 两款经典酱汁可供选择 —滨田酷感黄豆浓汁 —特调墨西哥辣椒烩酱 （煎饼果子）  特浓肉孜酱青葱拌意面 （杂酱面）  特调浓香酱蘸皇家白玉冰珂 （beancurd）（凉拌豆腐）  明前安溪茶蕊煎怀玉百合 （铁观音炒百合）  特制北冰洋鳕鱼汁至鲜布丁 （鱼冻）  西班牙热辣风情茴香桂皮油灼鱼排 （水煮鱼）  法式松脆芝麻小烤饼配墨西哥特制油煎香面卷 （烧饼夹油条）  意式酱汁淋细面饼包裹浓香美国小肥牛 （牛肉锅贴）  泰国翡翠珍珠梗卷中式黄金炸脆饼（甜/咸）（瓷饭团）  特制西班牙浓香茄汁烩日式香Q小猪肉条 （茄子排条）  传统烤茄瓜红烩浓香肉汁（肉沫茄子）  西班牙青椒红烩利大意小牛眼肉片 （青椒炒肉）  特调美味酸甜汁烩澳大利亚小尖椒 （虎皮青椒）  精制小麦面饼包裹浓汁肉眼扒 －－－ 肉包子  中式松花蛋烩特选猪肩肉配水晶香稻浓汤 －－－ 皮蛋瘦肉粥  白水炖煮精选五花肉配橄榄油油滚墨西哥特大青辣椒(青椒回锅)  意大利秘制风味水煮五花肉爆鲜青椒（水煮肉片）  海鲜杂烩配时蔬小菜浇中式意面（三鲜面）  豆腐脑：中式豆花布丁配特制鸡丝浇汁佐顶级蒜蓉辣酱  油条：精选花生油炸发酵汤种咸味法棍  盐渍乳黄瓜色拉配油醋汁及蒜醋汁——拍黄瓜  蒜泥沙司橄榄油沥茄瓜碎——过油茄子  白酒乡村浓酱汁焗鸡胸肉——红烧鸡

自己的笔记。。。。

基本上这样就可以实现分页了。。。当然，这是最基础的。因为实在没时间 仔细看zii的CgridView

我在dongbeta的网站上看到了这个东西，突然觉得原来子域名真的很简单，原来我还在想，如何绑定一些子域名的事情呢。

看一下原文吧，然后说明一下，官方的手册中其实已经有类似的介绍了，只是目前这一部分还是英文版的，这可能和这个功能是最新刚加入的关吧。。来源网址为：http://dongbeta.com/view/655

--start--

Yii强大的路由功能配置相当灵活，特别是增加了参数主机名路由功能之后更是可以灵活控制域名。感觉每一次提出一个提议，Yii的开发者qiang如果采纳，就会给出一个我没有想到却更加强大的解决方案。这次就是这样。

下面就是可以将所有子域名都转化为模块的路由规则，来自Yii官方论坛的一个帖子：

规则写在main.php中的组件配置数组里面：

标题这种话已经在被很多人所理解，现在大多数开发人员已经不再把语言当成障碍，而是把思想当成障碍，语言的跨度其实真的很容易解决，但思想不进步，你有着再好的语言又怎么样？即使你用的是所谓的自然语言（即平时生活中的语句），但只要你没有思想，没有逻辑，你又能写出什么样的程序？

以下内容来自老王参加的某大会的记录、摘要。我是看中其中的一小部分，觉得有感触。。原文在这里，点击进入：

部分我认为不错的精华，或者说是我关注的。。。

1、课程：失败来临的征兆（讲师：Michael Nvgard）这一切正是Michael Nvgard先生演讲的主旨：意外的问题总是在不经意间发生，要注意把它们的影响限制在局部，避免拖累整个应用。比如说在SOA中集成若干个服务时，应该 设置好各个服务的Timeout，避免其中一个服务崩溃连带整个系统等待。

2、课程：Twitter的可伸缩性数据架构（讲师：Nick Kallen）

Nick Kallen介绍了Twitter在处理海量数据时的经验，其实总结出来就三条：分区，索引，复制。

着重介绍了Tweets，Timelines，Social Graphs，Search Indices四个基本功能的实现：

Tweets比较简单，就是分区，虽然可以使用id或者user_id来分区，不过目前Twitter使用的是按time分区。

Timelines相对复杂了一些，最开始采用的方法是纯SQL的，大致如下：

这当然不是一个高效的解决方案，后来采用了被称作离线计算（Offline Computation）的解决方案，其思路大致就是每当发送一条推的时候，采用队列存储避免峰值瓶颈，同时向所有Followers分发此消息，然后每 个分发 终端在缓存中完成合并计算。乍一听起来这似乎也不是什么好的解决方案，一旦某人有非常多的Followers，即便分区，这个分发操作也会非常耗时，但按 Nick Kallen的介绍，Twitter确实是这么做的，细节操作有待研究。

剩下的问题不多说了，Nick Kallen给了PPT地址：http://www.slideshare.net/nkallen/q-con-3770885

3、课程：构建可扩展的微波系统（讲师：杨卫华）

杨卫华作为新浪微博的架构师，这次的PPT做得很酷，虽然在内容上和Twitter有些重复，但还是很不错。

提到了Memcached的evictions问题，给出了三个守则：

1：规划好cache的容量
2：将永久数据和临时性数据分开
3：不使用随机字符串做Key

至于原因，可以参考杨卫华的博客上的介绍：Memcached数据被踢(evictions>0)现象分析

4、课程：敏捷在中国（讲师：Tom Mellor） 编程工期的催促往往让程序员只考虑眼前的既得利益，却忽视了后期的风险。

5、课程：如何在团队中有效实施TDD（讲师：麦天志）在阐述为什么即便工期紧张也应该使用TDD的时候，他给了一个比喻：医生做手术的时间很紧张，但即便 这样，手术前清洗双手的工作程序也是必不可少的。在讲解重构时，他强调了TDD是重构的基础，只有这样才能保证重构没有改变现有的行为，否则就不是重构，而是重写。

我也来个前言，架构这东西，研究的人越多，我能够做参考的也就越多，哇哈哈哈。不多说，贴copy来的文章，原文见博客园：http://www.cnblogs.com/micronet-lukey/archive/2009/04/14/1435520.html。

当然这个架构和我们传统意义上的WEB架构不太一样，但我想说的是这些问题还是可以作为一定的参考。比如我们在开发的时候，是直接上SVN还是采用传统的目录共享式开发。现在SVN已经成为很多项目开发所必备工具了，但如果我们在部署的时候采用SVN进行分发代码呢？审核关如何过？

程序员->发送到SVN服务器->SVN分发到测试组->测试组分发到正式机

这是一种解决方法，其实也有点象下文的图片。但实际操作中，当然不太会这样操作。不过也差不多是类似的方法。

让我注意的其实是文章的最后一句话。。。

前言：

       目前，公司的呼叫中心程序已经在中国的很多城市运行着。由于受到技术和网络环境的限制，这些呼叫中心程序安装实施完毕后，我们都是采取客户先反映问题，然后我们再安排人员时间进行维护。这种被动的维护机制带了很多问题。

目前存在的问题：

一：客户在描述问题的时候，并不能深入到系统的内部，往往只是描述了一个系统报错的现象。由于公司里已经没有当时的运行环境，在公司内很难做到故障重现，也就很难定位到故障的原因。系统维护和bug修补难度很大。

 二：呼叫中心的程序日志都是分散存放的。哪台计算机中的程序报错，就到那台电脑中找出错日志。这个过程必须人工干预。有时候，有些报错内容非常致命，但由于公司不能及时获取到这些信息，导致很多问题就像一颗定时炸弹一样无法及时排除。

 三：当公司更新了一个版本后，如果不能到现场维护，只能通过远程或者让客户代劳替换新程序。这种更新机制一旦遇到网络中断，或者客户不配合，将给维护工作带来很大障碍。如果由于需求变更较多，需要经常更新版本， 那么面临的问题将很难解决。

 解决的措施：

就第一和第二个问题，可以通过改进目前的日志记录方式来解决。通讯服务器接收客户端程序的错误日志。并且把这些日志内容打包成E_Mail邮件，定时发送到公司指定的邮箱中。

就第三个问题，可以通过自动更新服务来解决。维护人员把最新的软件更新包上传到客户端的通讯服务器中。客户端程序监测到有最新的软件更新包，可以自动更新。

 

解决问题的核心就是在客户那安装一台通讯服务器。这台通讯服务器既要能能够连接到Internet，同时还要和内部的服务器向连接。这台通讯服务器有两个作用：

1：发送各个程序的错误日志到公司的邮件。

2：接收公司上传的程序更新包，并自动通知各个客户端程序更新。

所有的工作都由服务器自动完成。

 总结：

       任 何一个系统，在现场部署完成，用户正式开始使用后，对于我们开发组来说，那只是万里长征走完了第一步，后期不断地查错，改进，更新，替换也会占用到大量的 人力物力，如果是外省的客户，跑一趟现场还会占用大量的财力。按照现在的技术能力和网络环境，我们完全可以通过技术手段，更高效地对各个系统进行维护。

维护的最高境界是：客户还没有发现问题，我们已经捕捉到bug并在后台悄悄地把程序更新了。