Category Archives: 业界杂谈

AI谱曲与舞蹈

2024 年 06 月 30 日 – 下午 1:03

本文介绍两个好玩的AI工具，都是今年上半年新推出的，都是国外的的网站，趁现在不用魔法就能白嫖，有兴趣的可以试试：
第一个是AI作曲网站，suno.com，这是我用它谱的曲子，歌词是用chatgpt写的，大家可以听听效果
春之歌 >>
操作不复杂，只要在create页面，上传歌词、设定曲风就可以了
第二个是AI合成舞蹈，viggle.ai，这个用起来相对复杂一些，要选择一个舞蹈动作模版，再选一张四肢清晰的正脸照片，就可以了。这是它的官方宣传视频，

需要注意的是，一定要选正脸照片，否则AI可以能给换张脸^_^；一定要选四肢清晰的照片，不能是穿裙子之类的衣服，否则AI区分不出四肢，出来动作会很奇怪
——over
转载请注明出处: 昆仑的山头

Tags AI | Permalink | Comment (0)

Hello World 业界杂谈

QCon琐记

2015 年 04 月 27 日 – 上午 8:35

上周有机会参加了一天半的QCon，虽然感觉QCon越来越水，但是还是有些收获的，这里简单记录下来

Nodejs

其实，这次QCon没有nodejs的主题[汗]…，正因为没有，反而说明nodejs的热度已经过去了。

曾经火了两年，现在，曾经感兴趣的都已经体验过了，估计和我感受一样，nodejs不过是前端工程师偶尔玩玩后端的玩具，真正适合用nodejs的项目并不多。

而从前端js迁移到后端nodejs的学习成本，并不亚于从0开始学php这类简单脚本语言！

除了学习成本高，nodejs其他两个让人不爽的地方：

异步，导致代码回调嵌套太深，而后来给出的解决方案又太麻烦，可操作性不强
npm库太乱，很多工具包更新不及时

而所谓统一前后端语言，个人觉得也完全没有必要：分开前后端，让开发者更清楚Http的界限在哪儿，哪些是跑在你服务器里的，哪些将运行在用户浏览器里。前后端的工作方式差别太大，所以了解这些，对开发者很重要

不过瑕不掩瑜，碰到需要webscoket的地方，nodejs还是很有优势的，去年年初做的一个nodejs小项目现在跑的还很平稳

全栈开发

所谓“全栈开发”，现在还没有统一的定义，大部分人得理解，就是一个人可以解决前后端的所有开发，至于说还要解决UI、测试，甚至还要自己扛机器，那就纯粹扯淡了

全栈到底是好还是不好，个人觉得视实际的公司、项目而定，如果是有很多业务的新公司，总是会有各种探索性的小项目，那么全栈工程师的优势明显：机动灵活，节约人力成本。

反之，如果是已经成体系的“大”项目，那么还是将前后端分开的好，这样即便于维护、也可以让各端做的更精。

因为人的精力有限，能做到“全栈”，就意味着都不会太专业。

小之美好

这是一个妹子讲自己所做的公共插件的主题，大意是，将功能庞大的服务项目，解体成一个个单独功能的小服务，其实这也是近几年软件工程的主要方向

将一个个小服务做好、做精，各个小服务都可以单独修改、单独上线，这样就能更加机动灵活、提升开发效率，降低维护成本

创业团队

开发人员如何创业，或者说技术如何参与到创业团队中，由于本人刚刚参加过一个创业团队，所以对相关的一个讲座深有感触

讲座提到一个4个人的创业团队，一个前端，三个后端，前端除了负责前端开发，还要负责交互和视觉；后端除了负责后端开发，还要负责产品功能。这样的一个团队，做出来的产品，并不亚于有很多产品大牛主持的东西

这里并不是说要干掉产品经理，而是尽量让技术也能参与到产品的设计中

如何让技术可以全身心的投入到开发中，最简单的办法不是拼命压缩项目周期，而是让技术本身觉得是在做自己的项目，所谓“将士用命士子用心文不贪财武不怕死”，这样不仅开发效率更高，开发质量也会比仅停留在“简单做事”层面高的多

水电工

这个不是QCon的主题，纯粹是自己的一点心得

虽然我自己经常自嘲开发工作就像建筑工人，但二者还是有本质差别的：一个房子，必然是一砖一瓦建起来的，但是一个项目，却不一定真的需要一个字符一个字符的敲到电脑上~~

如果非要做个类比，开发者更像装修中水电工。水电工布设的各种管线，最终会被瓷砖、墙漆盖上。专业，或者说有良心的水电工会按照规程去布设管线，即使它们后来被盖上了，再来一个水电工要修改线路的时候，或者说其他人需要在墙上做打孔操作的时候，只要看到线路的入口和出口，按照一般的规律，就可以轻易的判断出线路的走向

更有甚者，在你之前，比如房子建设阶段就已经埋设了一些管线。如果一个水电工发现了这些基础设施，并且能够正确使用它们，就可以大大节省业主的成本

而专业的开发者正是需要这样的匠人精神：不见得什么东西都要自己从0做；自己做出的东西，也是对后续开发者友好的

轻应用

两、三年前，就在大家都忙着做所谓移动端“web app”的时候，却苦于找不到优秀的“母体”

使用普通手机浏览器？手机端浏览器种类比pc端更乱，兼容起来太难，而且不仅入口需要用户输入url，还需要注册之类的流程，用户入门门槛有点高

自己做app？自己能做app，干嘛还要搞体验要差一些的“web app”？

就在这时，微信公众平台很空出世，消息/扫码解决了入口问题，oauth解决了注册/登录问题，新出的jssdk，还可以实现很多普通web页无法实现的功能

可以预计，未来两年，基于微信的轻应用、小游戏会越来越多、越来越火

Permalink | Comment (0)

Hello World 业界杂谈

[转]别闯进Hybrid App的误区

2014 年 03 月 22 日 – 上午 3:41

【引言】

Hybrid App，一种开发模式，兼顾Web和Native的一种开发模式。有人说它把Web App扼杀在摇篮里，有人说它把Native App引向一个新阶段。我说，它是一把双刃剑，千万别闯进它的误区。本文是笔者在实践Hybrid App开发模式过程中总结出的一些经验教训，供读者参考。Hybrid App虽好，可万万不能仓促选择，盲目运用。

智能手机日益普及，移动互联网乱战日趋白热化，开发一个应用早就不是技术圈热议的话题，iOS和Android上的App已经成了每个互联网产品的标配。“唯快不破”也是中被移动互联网人尊为铁律，快速迭代，高效开发，低成本上线是每一个App开发团队追求的目标。同时，随着HTML 5的不断升温和智能手机硬件性能的提高，Hybrid App的概念应运而生。这种“Native搭台，HTML 5唱戏”的Hybrid App开发模式一时间受到各个开发团队追捧，快速进入了大量开发团队，成为主流开发模式。

Hybrid App优点众多，Web前端工程师0成本介入，不依赖版本的实时更新，快速实现跨平台需求，等等。而另一个方面，2012年Hybrid App的践行者Facebook决定大量弃用App中的HTML页面，转向更加Native化的方案。Facebook的这一举措也给Hybrid App方案的敲响了警钟，这似乎并不是一个完美的方案。

本文主要跟大家分享一下我团队和个人在Hybrid App的实践中遇到的问题，提醒大家不要闯进Hybrid App的误区。

误区一：为了HTML 5而Hybrid App。

HTML 5在Hybrid App模式中是一个最常被提起的概念。HTML 5作为一个HTML 4.0.1和XHTML 1.0的升级版，基于旧版本有更强大的表现功能，并加入了Local Storage等技术，确实为Web页面提供了更大的想象空间和更多的可能性。但HTML 5处在目前的发展阶段，受到浏览器兼容性和手机硬件性能水平的影响，它所能提供的功能与Native仍然有很大差距。

所以，我认为作为工程师要明确一款App采用Hybrid App模式的根本原因是什么。作为一款App其最根本的功能是满足使用者的需求，而并不是服务某项新技术。因此当决定采用Hybrid App去构建一款应用时，应该从应用本身功能特点和整个团队的开发资源配比统一考虑，是否有必要同时又有能力去驾驭一款“Native搭台，HTML唱戏”的Hybrid App。类似“HTML 5的时代已经到来，如果我们不这么做就变土鳖了，错过这场技术革新的大潮，终将被这个时代所淘汰”的话真不是一个有责任心的工程师应该发出的声音。

误区二：忽略关键因素

在谈到Hybrid App的场合我们更多提及的是它有诸多优点，如何架构一个Hybrid App，怎么让Web和Native和谐共处，然而Web开发中会被忽略的一些因素少被提起，这些因素又恰恰经常是一个Web页面能否正常运行在App中的决定性因素。

Web开发是基于PC的一种开发模式，开发者使用PC浏览器模拟App中的Web View进行调试。PC浏览器与手机Web View的区别是巨大的，能支配的CPU资源，最大占有的内存，运行的网络环境，鼠标操作与触控操作的区别，浏览器对CSS/JS的解析和对事件处理，等等。

App工程师，无论是iOS还是Android，最敏感的一个问题莫过于内存管理，而在Web开发则对这个问题没有过多注意。这就经常导致同一个功能界面Native实现中会通过一些技术手段，把内存容量控制在操作系统允许的范围内保证App正常运行。如果以Web方式接入App的页面没有一个明确的标准和严格的验收机制，相应的Web实现则不会过多考虑这方面的问题，而且浏览器也没有给前端工程师提供足够的Api支持处理内存问题，导致在某些条件下造成App无法正常运行，甚至Crash。

同样的问题会出现在网络环境方面，虽然现在wifi覆盖越来越广，3G网络也日益普及，但App运行的网络环境与PC相比仍然有着巨大差距，wifi和蜂窝网络的切换，基站变化等诸多因素都会导致网络间歇性断开。Web开发总是默认有一个稳定的网络环境，因此在对于不稳定网络环境问题的处理上也有所欠缺。没有明确的对于低速网络或不稳定网络访问的处理，在很多情况下这些页面也会非常不给面子。

误区三：富交互导致体验差

这里所谓的体验问题一分为二：一是与手机平台默认交互习惯不一致的体验，二是与同样功能Native界面存在的体验差距。

无论在Android还是iOS平台上，都有各自的一套交互习惯，包括视觉风格，界面切换，操作习惯等，与Web习惯完全不同。如果使用Web方式开发富交互的页面，或多页面功能就会出现这样的问题。

以iOS界面切换为例，系统风格是新界面自右向左推入，后退时界面自左向右推出，而旧界面保持状态。Web开发的默认习惯则是刷新页面，无论新载入页面或是后退，都会对页面进行刷新。因此使用Web模式开发多界面功能就面临这样的交互习惯差异，造成体验上的损失。当然Web方式也可模拟Native的交互方式，但这样的模拟首先提高了开发成本，有悖于最初的高效原则，从效果上看，也很难达到Native的流畅性。

另一个方面，也是上述提到的与Native相比，同样的功能在性能上存在巨大差距。Web界面上JS对HTML Node的操作需要消耗大量的CPU资源，手机CPU的性能还不能与PC相提并论，就算在智能手机之间，硬件水准也参差不齐，一个可以在iPhone 5上流畅运行的界面，跑到三星S III上很可能就卡住不动了。所以我们经常可以发现一些富交互页面上的操作无法达到令人满意的流畅度，而流畅度也正是用户评价一款App优劣的最直观因素。

误区四：跨平台

一次开发，跨平台运行是Web的优势，这也是很多App采用Hybrid模式的重要原因之一。兼容性问题在Web开发过程中往往不被关注，但当下智能手机的软硬件版本众多，兼容性绝对是一个不容忽视的问题。

以Android手机为例，诸多主流品牌都有各自定制过的操作系统，浏览器内核对JS和CSS的解析，事件处理等方面都存在区别。以HTC One为例重叠在一起的层在某些情况下会对点击事件透传，而其他多数平台则不存在这个问题。并且目前移动平台的开发框架还没有完全成熟，可以很好的解决兼容性问题。所以就要求开发者在开发过程中要对兼容性做充分测试，对于某些特殊版本进行特殊处理。

即使在相对统一的iOS平台，不同版本之间也存在较大差异。例如：在iOS 4.x版本中CSS甚至不支持position fix的属性，4英寸屏幕的设备无法很好的支持apple-mobile-web-app-capable属性，等等。

误区五：交互一致性。

交互一致性是一个非常容易被误读的概念，“一致性”经常被理解为同一个应用在各种平台和场景下要有一致性的体验。我认为在移动平台开发过程中，“一致性”应该是App视觉和交互习惯与其运行平台的习惯保持一致。而Web开发“一次开发，跨平台运行”的特性与此存在一定程度上的冲突。

以“返回上一页面”的操作为例，在iOS平台上在页面顶部始终存在一个44像素高的导航栏，左侧有一个返回按钮用于返回操作，而Android平台则习惯使用设备提供的返回键操作。这个返回按钮在iOS平台可以通过绝对地址的方式连接到任何其他页面，而在Android平台返回按钮和设备的返回键则可能指向不同的位置。

例如这样的一个流程：首页->列表->筛选->刷新过的列表，此时的返回操作被期望是导向首页，则页面上的返回按钮可以通过绝对链接的方式实现，而Android设备的返回键则只能返回上一个筛选页面，再次返回是筛选前的列表页。

Hybrid App方案是一把双刃剑，一方面它平衡了Native App和Web页面的优缺点，一定程度上解决了Native App开发过程中迭代慢，版本依赖，Native开发资源不足的问题，但另一个方面过度依赖Hybrid方案会造成Web前端开发成本快速上升，甚至造成App整体体验下降，甚至造成功能缺失。

不要为了Hybrid而Hybrid，控制好方案中Native与Web的边界。

扩展阅读

较早Mobtest针对Facebook的iOS App专门做的一片评测文章，阐述了使用大量HTML页面的App出现的问题：http://blog.mobtest.com/2012/05/heres-why-the-Facebook-ios-app-is-so-bad-uiwebviews-and-no-nitro/

资深开发者@李秉骏在InfoQ发表的《Hybrid App实战》，阐述了Hybrid模式的优势与劣势，并简单介绍了开发Hybrid App所需的技术储备，供读者参考。：http://www.infoq.com/cn/articles/hybrid-app-development-combat

资深开发者@唐巧较早对Hybrid App主流框架PhoneGap的分析文章，笔者非常同意对PhoneGap框架的态度，PhoneGap虽好，可不要贪杯哟：http://blog.devtang.com/blog/2012/03/24/talk-about-uiwebview-and-phonegap/

————–
转自infoq：http://www.infoq.com/cn/articles/hybridapp-misunderstanding

Tags webview | Permalink | Comment (0)

Hello World 业界杂谈微信开发

微信公众平台的新功能

2013 年 11 月 06 日 – 上午 11:46

在犹抱琵琶半遮面了N久以后，小伙伴们期待已久的新版微信公众平台后台终于上线了，这次上线的，不仅有页面的改版，更带来很多实用的新功能

比如统计功能，可以统计用户、消息的各种数据
再比如商户功能里支付测试支持，以及对浏览次数和成交量的统计

当然啦，对于开发者来说，最吸引我们的还是伴随而来的新开发的各种接口以及姗姗来迟的调试功能

“微信公众平台接口调试工具”是一个很好用的功能，可以让我们在不使用服务器的情况下就可以调用各种接口，估计以后会很常用

下面，我们来盘点一下微信公众平台对普通公众号开发的接口们

1. 基础接口

2. 消息相关

3. 自定义菜单相关

4. js api

当用户在微信内置浏览器访问我们的页面时，我们可以通过jsapi做下面的事情

a. 获取用户网络状态，包括wifi、2G、3G

b. 隐藏右上角分享按钮、隐藏网页底部导航栏，让你的页面更像原生应用

5. 地理位置相关

6. 用户信息

b. 获取用户基本消息
“关注者与公众号产生消息交互后”，公众号既可以获得该用户的基本信息，包括昵称、头像、城市、性别等

c. OAuth2.0
当用户在微信内置浏览器访问我们的页面时（不需要必须关注公众号），我们就可以获得访问者的openId，以及用户的其他基本信息
如果你执行获得访问者openId，通过几次redirect，和普通的OAuth过程是一样的
如果要获得用户基本信息，微信就会弹出授权界面，并且每次重新再试图获取用户信息是，微信都会弹出授权界面

d. 获取关注者列表
终于有了同步所有关注用户列表的接口了！

e. 扫描带参数二维码
这是一个相当强大的功能，可以让用户扫码后自动关注你的公众号（需要用户点一下“确定”），同时你还可以给用户回复一条欢迎信息

上面只说了微信开发接口的功能，具体的接口地址、参数什么的，同志们可以自己到公众平台的开发者文档里去查询

———
参考：微信公众平台开发者文档

Tags 微信公号 | Permalink | Comment (1)

业界杂谈

微信

2013 年 07 月 03 日 – 下午 11:32

虽然微信已经出来2年了，作为一个对新鲜事物不甚敏感的人，我是从三个月前，因为要为公司做微信相关的项目，才开始关注微信的
开始的时候，还以为微信api就像微博一样，也就是发发微博之类的功能，但仔细看了微信公众账号的api以后，最大的感觉就是：哇塞，这玩意好牛逼~~~微信并没有说自己可以干什么，却也没说自己不能干什么~~~微信就是一个一对一的交流平台(当然，也可以一对多)，可以文字、图片、位置、语音~~就像两个人聊天一样，所以能通过聊天做的事，通过微信也能做

昨天的腾讯合作伙伴大会，下午的微信专场里，除了介绍5.0的新功能意外，还有十个来自各行业的微信公众账号做经验介绍，这其中，既有各类企业用户，也有如广东公安这样的政府部门，在他们的使用中，大概包括了下面的功能

1. 客户服务
基于微信的一对一交互，客服平台是最常见的微信功能，甚至不需要对它做什么开发，直接使用腾讯自身的微信后台就可以完成这个功能
2. 营销
虽然腾讯并不想让微信成为营销工具，并且给群发功能加了很多限制，但却也挡不住用户从微博上继承来的习惯，不过效果怎么样，就很难说了
3. 查询
比如说，在做了账号关联后，查询订单信息，查询信用卡账户信息，查询的介质，可以是文字，也可以是语音、图片、以及位置
4. 替代APP，完成更加复杂的功能
对于界面要求不高的应用，完全可以使用微信公众账号替代APP，比如生活服务类的应用出门问问，完全没有APP，通过微信实现所有的文字、语音的问询服务等功能

在5.0的微信，还将加入微信支付的功能，这样，一大批电商就可以直接在微信里卖东西了

关于使用微信的一些使用建议，@青龙老贼给出建议最有参考价值：互动塑造品牌，服务创造价值，走原创化精品化专业化的道路

Tags 产品 | Permalink | Comments (4)

Hello World 业界杂谈

nodejs-express初体验

2013 年 05 月 30 日 – 上午 8:59

上次文章提到，正在用nodejs做一个小项目，现在总算是做完了

学习/搞着玩是一回事，虽然两年前就开始接触nodejs，做实际要用到项目里是另一回事，经过两周的折腾，我这里不想夸，也不想踩，只想说一下我真实的感受，给准备用nodejs的朋友一点参考

整体来讲，nodejs+express的开发模式，感觉还可以，既不像前端大牛们说的一样好，也不像另一些人说的那样一无是处，下面针对几个关键点分别说一下

1. express

早就听人说过，express是个“优秀”的web框架，我这次的使用体验，却让我没有这种感觉。大概是用惯了cakephp那种规约编程/傻瓜化的web框架的缘故，我觉得一个框架最应该做的，就是让使用者不要过多感觉到框架的存在，以最简单的方式获取请求参数/调取model/lib/以及向view层传递显示，可以让人将所有的精力都投入到业务逻辑中～～要不我还用你框架干嘛？

对express，最别扭的一点，就是它的routes配置～～居然每一个请求的url都要去做配置，让我一下想到了java/spring mvc的那个xml～～懒婆娘的裹脚布也不过如此

另一个sb的地方，是它的logger～～本来不想重写日志类的，特别是access日志，服务器能自动记录最好，找了好久，才找到如何设置express 日志的格式，可是设置好以后，发现日志时间记录的不对，格式也不好看，一查原码才发现，logger里用的是date.toUTCString~~UTC啊，尼玛我看日志的时候，还得想着和实际时间差8小时。。。

最关键的一点是，express官方的api极其“简约”，很多东西不得不去翻框架原码才能发现一些“隐藏”的功能

最后，作为一个web框架，居然没有filter，虽然app.use可以部分实现filter的功能，但用起来还是感觉很不爽

2. npm

npm真TMD乱，很多好名字都被占了，占着茅坑不拉屎

比如thrift，装上以后发现根本不能用，版本太老，仔细一看，居然2年没维护了

再比如email，居然没看见在哪儿设置邮件服务器～～太TM扯淡了

3. 模板引擎

express默认的jade就不提了，稍微复杂点的页面，就会搞得一团糟

我用的是ejs，不好不坏，只能说“可用”。我比较喜欢view层代码，后端程序和前端html/js可以一目了然，所以我使用<%作为格式符，然后用jsp编辑器打开ejs文件～～哈哈，一目了然

ejs比较不好用的一点是对于变量的判断过于严格：如果试图输出没往view层传递的变量，页面居然会直接抛500错误～～太较真了吧，你当空串处理不久行了吗？

4. nodejs

不好意思，上面说了3点，大部分都是在踩，现在该说点好的了

js&node，本身还是一款很不错的组合，虽然异步编程需要一些时间来适应，但却给高并发和快速影响带了了天生支持；另外，js语法简单自由，也可以带来很高的开发效率

对于所谓的“前后端共用代码”，我倒是觉得不太有必要～～毕竟，前后端执行环境差异巨大，写这种“公用代码”的维护成本，还不如直接copy一份给前端用

最后，给自己留一个问题：下次你还会选nodejs吗？

以前写过一个简单的前端mvc框架，jLeaf，基本思路是模仿cake和spring来做的，node出来后，曾经想顺势再写一个后端框架，名字就叫jRoot，可惜因为工作忙，也因为人懒，没能实际做出来，看到express这么难用，真想现在就把jRoot做出来，可惜现在更忙了～～～希望后面能有时间把它搞出来，也希望node能有其它更好用的web框架出来

Tags express, Node.js, 框架 | Permalink | Comments (4)

Hello World 业界杂谈点点滴滴

php ci快速入门

2013 年 02 月 25 日 – 上午 11:08

久闻php ci的大名，一直没有机会使用，上周做个小项目，用到了这个框架，整体感觉很不错，这里跟大家分享一下ci的快速入门

ci文档入口：http://codeigniter.org.cn/user_guide/toc.html（中文！）

ci，即codeigniter，我用的版本是当前的最新版本2.1.3

使用ci，只要将apache或者nginx的发布目录指到codeigniter的顶级目录下就可以

下面，就按MVC的顺序来所说ci的使用

url

比如要访问/news/list的action，默认情况下，url需要这么来写：xxx.xxx.xxx/index.php/news/list~~多个index.php，很别扭

如果要去掉这个index.php，需要加上“.htaccess”来实现urlRewrite：

1
2
3

RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

ci的controller位于application/controllers目录下，文件名和ation方法名需要遵循规约变成的规则

不多说了，还是直接写代码吧：

class News extends CI_Controller{
	function __construct(){
		parent::__construct();
	}
	// http://localhost/news/lists，如果要使用其他的url，需要到“application/config/routes.php”去配置路由
	public function lists($keyWords){
		//使用model，model()方法的第一个参数“news”对应application/models/news.php
		//第二个参数“News”对应下面如何引用这个model：$this->News，如果不设置这个参数，这是$this->news，及model的名字
		$this->load->model('news', 'News');
		$data['list1'] = $this->News->list_all();
		//使用library核心类
		$this->load->library('news_manager');
		$data['list2'] = $this->news_manager->search_news($keyWords);
		//使用view，向浏览器输出内容
		$this->load->view('header');
		$this->load->view('news/list', $data);
		$this->load->view('footer');
	}
	//
	public function view_news($id){
		$this->load->view('view_news', array(
			'title' => news->title,
			'content' => $news->content
		));
	}
}

如果要加载非默认数据源，需要到config/database.php里配置不同的数据源，比如现在除了default，又添加了一个叫做abc的数据源，我们如何调用哪个它哪？

//abc
$abc = $this->load->database('abc', true);
$this->load->model('abc_table1');
$thisi->abc_table1->db = $abc;
//default
$defaultdb = $this->load->database('default', true);
$this->load->model('news');
$this->news->db = $defaultdb;
//即通过“$this->load->database”建立数据源，然后通过$thisi->model->db=xxx为当前某个model的引用设置数据源

另一个要说的功能是：可以将controller文件放在子文件夹中，比如“application/controllers/shop/products.php”，调用它就需要“/index.php/shop/products/xxx”

上面的代码已经用到了模型的调用，这里所说模型的常用方法

增

class news extends CI_Model{
	function __construct(){
		parent::__construct();
	}
 
	function cretae($title, $content){
		$data = array(
			'title' => $title,
			'content' => $content,
			'create_time' => new time()
		);
		//INSERT INTO news (title, content, create_time) VALUES ('xxxx', 'xxxx', 'xxxx')
		$this->db->insert('news', $data); 
	}
}

删

//DELETE FROM mytable WHERE id = $id
$this->db->delete('news', array('id' => $id)); 
//等效
$this->db->where('id', $id);
$this->db->delete('news');

改

$data = array(
	'title' => $title,
	'content' => $content,
);
$this->db->where('id', $id);
//UPDATE news SET title = xxxx, content = xxx where id = $id
$this->db->update('news', $data);

查

//SELECT * FROM news
$query = $this->db->get('news');
//select * from news where id = $id limit $offset, $limit
$query = $this->db->get_where('news', array('id' => $id), $limit, $offset);
//直接取结果集
$list = $query->result();
//取结果集的数量
$count = $query->num_rows();
//此外，ci的查询还有丰富的方法，支持各种查询，诸如：where/or_where/where_in/or_where_in/like等等

打印sql

1	echo $this->db->last_query();

ci的view位于application/views/目录下，比如view_news.php，可以直接使用php代码书写

<html>
<head>
	<title><?php echo $title;?></title>
</head>
<body>
	<h1><?php echo $content;?></h1>
</body>
</html>

上面的title、content参数，可以通过下面的方式在controller中传递过来：

$this->load->view('view_news', array(
	'title' => $news->title,
	'content' => $news->content
));

———
参考：http://codeigniter.org.cn/user_guide/toc.html

———
蒋评：
先不论框架的易用性、性能等因素，相对于cakephp和thinkphp，ci最大的又是就是它的中文资料丰富，有完整的中文文档，甚至官网还提供中文视频教程：http://codeigniter.org.cn/tutorials，这些都大大降低了新手的入门难度[赞]

Tags ci, php | Permalink | Comment (0)

业界杂谈他山石

关于WebKit的几个问题

2013 年 02 月 17 日 – 上午 6:37

1. WebKit是什么？

WebKit是一个开源的Web浏览器引擎。
WebKit的HTML解析器和JavaScript解析器代码分别源自KDE的KHTML和KJS代码库。

2. 谁在使用WebKit？

“MacOS X系统的Safari、Dashboard、Mail和很多其他OS X程序”
这就是在说，WebKit是Safari背后的浏览器引擎。还需要补充的是，Apple在Safari里面使用了自己的Nitro JavaScript引擎（只用WebKit来渲染HTML）。

Google官方说明：Chromium使用WebKit做为渲染引擎。与其打造Chromium特有的实现方式，我们更希望去尽可能多的去为使用WebKit核心的浏览器做贡献。

这是说Chrome也在使用Nitro JS引擎？不，Chrome有他自己的V8 JavaScript引擎。简单的说，Chrome也使用WebKit，但是它也实现了自己的JavaScript处理方式。V8同时还是驱动Node.js的JavaScript引擎。

Opera会使用Chromium实现的WebKit，也会使用V8引擎。这就是说虽然Opera在宣称自己使用WebKit，但事实上它使用WebKit和Safari与其他浏览器使用的WebKit并不完全一样。如果你想客观了解现状，这是必须清楚的概念。

3. 现在WebKit究竟有多少分支？

所以我们知道现在WebKit正在驱动，或者将会驱动3个主流浏览器。但是WebKit还有多少其他类型的实现？
确实还有很多很多WebKit的变种，特别是在移动领域。他们都是WebKit的分支。

4. 这些WebKit的分支有多少差别？

有一种假设：因为这些浏览器都在使用WebKit，所以他们也会以同样的方式去支持相同的特性。
对于很多基本的特性来说，确实是这样。但是对于很多小众特性，就未必如此了。

举例来说，当Chrome开始支持游戏手柄API的时候，Safari不但还没开始支持，而且以后也不太可能支持。另一个例子是WebGL。做为在Chrome已经支持了很久的特性之一，Safari却才刚刚看到了曙光（而且还是在开发者选项里）。当然，这些还都是比较出名的例子。还有很多试验性的例子潜伏在大众的视野之下。

甚至很多基础的、日常的功能，在不同的代码分支下都有所不同。PPK完整的总结了这些WebKit的差异。

5. WebKit的逐步普及，对web开发有什么影响？

如果一个浏览器迁移到了WebKit，那是不是意味着（在编写代码的时候）可以少测试一个浏览器了？
不。每个浏览器都有它自己的怪异模式、性能差异、设计，和功能。所以每个浏览器都要测试。

当一个功能加入到WebKit的时候，是不是意味着在其他浏览器里就可以使用这功能了？
当然不是。比如游戏手柄API的例子。Paul Irish强调了这样一个事实：WebKit浏览器们可以挑选究竟把哪些API放入他们的版本。比如Chrome选择支持游戏手柄API。很多API在WebKit的层面就已经被实现了，但是WebKit项目书允许关闭这些功能。（编者注：Paul Irish是Google Chrome的员工，他曾在jQuery团队工作两年。）

如果所有的浏览器都使用相同的引擎，这对程序员来说意味着什么？
随着时间的流逝，他们会意识到尽管同是WebKit，也会有很多不同的东西。

6. 新特性如何加入到WebKit中，谁又来负责审核？

现在有许多公司正在为WebKit项目贡献自己的力量。

WebKit项目提交和审查页面提到只能有老的代码提交员和审核员才能提名新的新的代码提交员与审核员。这比较合理。然而，无论WebKit项目决定让谁参与进来，最终都还是要让Apple来做审核：
当有人被WebKit代码提交员成功提名后，Apple会处理发送代码提交员协议，在签署协议之后，Apple会继续开通SVN账户。

对于这一点并没有什么隐秘的动机，但这确实在告诉大家，WebKit和很多开源项目一样，并不是真正分散和民主的。权利是且必须是集中的——只有这样才能保证能做出决定，并且把事情做成。

7. 如何评价WebKit？

允许我们强调一下，WebKit是好的。它有开放的流程和强大的贡献者。我们只是想澄清一个当下被广泛接受的错误概念——一个WebKit等于所有WebKit，还有——如果所有浏览器都选择WebKit，那么对开发者来说，工作会变得更轻松。
我的意思是说，与众多独立的浏览器引擎会为市场带来多样性一样，WebKit在这一点来说，同样会表现的很棒。

—————

转自：http://www.infoq.com/cn/news/2013/02/webkit-history-and-now

Tags WebKit, 浏览器 | Permalink | Comment (0)

Hello World 业界杂谈

巧用setTimeout提高UI响应速度

2013 年 01 月 15 日 – 上午 10:45

关于javascript的性能问题，争议最多的就是它的单线程：UI渲染与更新数据跑在一个线程里，如果碰上比较耗时的数据运算或者DOM操作，UI就会很卡，特别是对IE6、7这些古董级的东西，这个问题会特别明显。
这里不想分辨单线程到底是优点还是缺点，只想所说如何通过setTimeout规避这种问题。
比如本博客上面红色的导航条(嘿嘿，换了皮肤，这个还没加)，当滚动条向下滚动时，通过修改css的position值，菜单条会变成悬浮在页面顶端的，在页面滚动过程中，js会不断检查当前滚动条的位置，直到导航条回到初始位置时，再将其定位回该位置。
由于要不停的访问DOM，取得滚动条的高度，这段代码在IE6、IE7里是很卡的，以至于刚开始的时候，我在这段逻辑的开头加了浏览器类型的判断，如果是IE，干脆不再执行这段代码~~~直到加入了下面这段优化以后

var scroolTime = null;
$(window).bind('scroll.top', function(){
  scroolTime &amp;&amp; clearTimeout(scroolTime);
  scroolTime = setTimeout(scroolFun, 0);
});
var scroolFun = function(){
  //.....检查页面高度、设置菜单条css的逻辑
}

上面这段代码的核心就是“setTimeout(xxxx, 0);”，咋一看，定时为0不是等于没定时嘛，其实不然，即使定位为0，setTimeout也不会立即执行定时的function，而是在当前线程空闲时才会执行，也就是说，随着滚动条的滚动，js逻辑会等喜面的代码跑完，且ui渲染完了以后再去调用 scroolFun。而“clearTimeout(scroolTime)”会保证定时队列里只有一个待执行的scroolFun

再比如，以前做的的一个需求，在js内上有一个几十到上千条的数组，数组内保存的通讯录的实体，页面上要求可以对通讯录做搜索。如果照正常的逻辑，需要将整个数组跑一遍循环，再将符合条件的结果集显示到页面上。特别是在做搜索的时候，需要支持随着用户输入的时时搜索，这种情况下，如果数组长度过千，即便是chrome这样的高端浏览器，页面操作仍然不回很流畅。
这是又到了setTimeout派上用场的时候了：每次对数组搜索时，只搜索10到100条不等的一段，搜索完这一段即将满足条件的结果显示到页面上，然后setTimeout(‘分段搜索function(start, length)’, 0)，等待线程空闲以后，再继续搜索下一段。
然后在用户修改搜索关键字时，记得要将上面的定时clearTimeout掉。
具体每次的搜索长度，可以根据浏览器不同来定义，不如IE6，每次只能搜索10条，而chrome每次搜索几百条。
—————-

Tags javascript | Permalink | Comment (1)

Hello World 业界杂谈

eclipse设置空格代替tab

2013 年 01 月 05 日 – 上午 9:04

随着node.js的流行，js的书写方式正在悄然发生变化。
node.js里异步编程的大量使用，回调越来越多，缩进也就越来越多，以前，习惯了tab/四个格的缩进，现在发现这种缩进方式对代码越多影响越来越大：缩进太多，内层的代码要靠拖动水平滚动条才能看到；另外，tab键在各个IDE里显示的空格个数是不同的，2~8个不等。
所以，就准备修改自己js的书写习惯：用两个空格代替tab。
但是，如果真的手敲空格又缺失太麻烦，还好大部分IDE都会提供使用空格代替tab的的功能，即敲tab后，实际产生的是另个空格。
下面介绍一下eclipse的设置方式，如下图，首先打开eclipse的“偏好设置”，找到图中所示的选项：

在Formatter找到“Active profile”，不要直接修改系统默认的profile，点下面的New，新建一个，然后打开，如下图所示：

在第一个选项卡里找到General settings -> tab policy，右侧的下拉改为“Spaces only”，下面的两个“size”都改成2，保存推出即可
———

Tags eclipse, javascript | Permalink | Comments (3)

昆仑的山头

Category Archives: 业界杂谈

AI谱曲与舞蹈

QCon琐记

Nodejs

全栈开发

小之美好

创业团队

水电工

轻应用

[转]别闯进Hybrid App的误区

【引言】

误区一：为了HTML 5而Hybrid App。

误区二：忽略关键因素

误区三：富交互导致体验差

误区四：跨平台

误区五：交互一致性。

扩展阅读

微信公众平台的新功能

微信

nodejs-express初体验

php ci快速入门

关于WebKit的几个问题

巧用setTimeout提高UI响应速度

eclipse设置空格代替tab

分门别类

时间线

链接表

七嘴八舌

近期发布

发布日历

2025 年 9 月
一	二	三	四	五	六	日
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Category Archives: 业界杂谈

Nodejs

全栈开发

小之美好

创业团队

水电工

轻应用

【引言】

误区一：为了HTML 5而Hybrid App。

误区二：忽略关键因素

误区三：富交互导致体验差

误区四：跨平台

误区五：交互一致性。

扩展阅读

五花八门

分门别类

时间线

链接表

七嘴八舌

近期发布

发布日历