易栈网-膘叔

现在的微博程序是越来越多，这种仅能输入少量文字的玩意吸引了越来越多的人。
有的人把它当成日记 ，有的人把它当成交友，有的人当成了推销，有的人当成了牢骚。总之，目前被它所吸引的人不在少数。
当成日记的是可以利用它写下自己的心情，而且不用对着日记本来写流水帐也会有很多的人看到。
当前交友的，则是可以利用##标记自己的关键词，以获取与相同想法的人交流的机会
推销的则更在意自己的粉丝有多少，当有上万上百万的粉丝时，自己说的每一句话，可是比在电视里的广告展现率更高了
牢骚嘛，其实很多人在做这种事情，无聊的话一堆堆的放上。
其实还有很多人在利用微勃，有招聘的，有二手交易的，有。。。。很多很多，线下你能想到的方式，其实微博都拥有了。

然而，终究这玩意只有140个字，它能用来做什么呢？为什么它是140字？而不是70字，50字？255个字？140个字的意义是什么 ？当然也有不是140字的，比如网易，就是163个字。
网上的传说 是因为Twitter最初的想法是想做类似手机短信的交流，所以SMS的70字就是他们的最大取值范围，事实上twitter也支持手机发送信息，所以这个理由可以被人接受。然后说传到国内因为中文是双字节，所以就成了140个字了，这个说法其实并不是能够特别认同，但目前也找不到可以论证的理由。我只能重推测是国内的人当然也认同70这个规范，但是1、可能觉得中文70个字能够表达的事情有限所以放大成140字。2、可能是大国思想在作祟，认为自己就一定要比别人多一点东西，于是就翻了一番。

虽然只有140字，可是掐架、求爱、求职、牢骚等等都拥有了，而且微博的各种手机客户端的推出，也使它成为了新闻的发布工具，任何人都可以发布自己的所见所闻到微博上，只是他们存在的时间比较短而已，为什么 ？你懂的。Just You Know Why?

140个字的世界其实很复杂。

这是一篇来自Yii官方的文章，写在了1.1.6的new fetures里面，值得一看，最起码，你在看完后，下次被人面试的时候，问到什么 是MVC，你可以有回答的东西了。

不多说，上原文，内容也不复杂，所以我就不翻译了（其实是我翻译不来，将就着看看可以，可是要翻译成人人都能看得懂的内容就难了）。。。

原文来自于：http://www.yiiframework.com/doc/guide/1.1/en/basics.best-practices，目前官方也确实没有中文版。

Although Model-View-Controller (MVC) is known by nearly every Web developer, how to properly use MVC in real application development still eludes many people. The central idea behind MVC is code reusability and separation of concerns. In this section, we describe some general guidelines on how to better follow MVC when developing a Yii application.

To better explain these guidelines, we assume a Web application consists of several sub-applications, such as

• front end: a public-facing website for normal end users;
• back end: a website that exposes administrative functionality for managing the application. This is usually restricted to administrative staff;
• console: an application consisting of console commands to be run in a terminal window or as scheduled jobs to support the whole application;
• Web API: providing interfaces to third parties for integrating with the application.

The sub-applications may be implemented in terms of modules, or as a Yii application that shares some code with other sub-applications.

1. Model 

Models represent the underlying data structure of a Web application. Models are often shared among different sub-applications of a Web application. For example, a LoginForm model may be used by both the front end and the back end of an application; a News model may be used by the console commands, Web APIs, and the front/back end of an application. Therefore, models

• should contain properties to represent specific data;

• should contain business logic (e.g. validation rules) to ensure the represented data fulfills the design requirement;

• may contain code for manipulating data. For example, a SearchForm model, besides representing the search input data, may contain a search method to implement the actual search.

Sometimes, following the last rule above may make a model very fat, containing too much code in a single class. It may also make the model hard to maintain if the code it contains serves different purposes. For example, a News model may contain a method named getLatestNews which is only used by the front end; it may also contain a method named getDeletedNews which is only used by the back end. This may be fine for an application of small to medium size. For large applications, the following strategy may be used to make models more maintainable:

• Define a NewsBase model class which only contains code shared by different sub-applications (e.g. front end, back end);

• In each sub-application, define a News model by extending from NewsBase. Place all of the code that is specific to the sub-application in this News model.

So, if we were to employ this strategy in our above example, we would add a News model in the front end application that contains only the getLatestNews method, and we would add another News model in the back end application, which contains only the getDeletedNews method.

In general, models should not contain logic that deals directly with end users. More specifically, models

• should not use $_GET, $_POST, or other similar variables that are directly tied to the end-user request. Remember that a model may be used by a totally different sub-application (e.g. unit test, Web API) that may not use these variables to represent user requests. These variables pertaining to the user request should be handled by the Controller.

• should avoid embedding HTML or other presentational code. Because presentational code varies according to end user requirements (e.g. front end and back end may show the detail of a news in completely different formats), it is better taken care of by views.

2. View 

Views are responsible for presenting models in the format that end users desire. In general, views

• should mainly contain presentational code, such as HTML, and simple PHP code to traverse, format and render data;

• should avoid containing code that performs explicit DB queries. Such code is better placed in models.

• should avoid direct access to $_GET, $_POST, or other similar variables that represent the end user request. This is the controller's job. The view should be focused on the display and layout of the data provided to it by the controller and/or model, but not attempting to access request variables or the database directly.

• may access properties and methods of controllers and models directly. However, this should be done only for the purpose of presentation.

Views can be reused in different ways:

• Layout: common presentational areas (e.g. page header, footer) can be put in a layout view.

• Partial views: use partial views (views that are not decorated by layouts) to reuse fragments of presentational code. For example, we use _form.php partial view to render the model input form that is used in both model creation and updating pages.

• Widgets: if a lot of logic is needed to present a partial view, the partial view can be turned into a widget whose class file is the best place to contain this logic. For widgets that generate a lot of HTML markup, it is best to use view files specific to the widget to contain the markup.

• Helper classes: in views we often need some code snippets to do tiny tasks such as formatting data or generating HTML tags. Rather than placing this code directly into the view files, a better approach is to place all of these code snippets in a view helper class. Then, just use the helper class in your view files. Yii provides an example of this approach. Yii has a powerful CHtml helper class that can produce commonly used HTML code. Helper classes may be put in an autoloadable directory so that they can be used without explicit class inclusion.

3. Controller 

Controllers are the glue that binds models, views and other components together into a runnable application. Controllers are responsible for dealing directly with end user requests. Therefore, controllers

• may access $_GET, $_POST and other PHP variables that represent user requests;

• may create model instances and manage their life cycles. For example, in a typical model update action, the controller may first create the model instance; then populate the model with the user input from $_POST; after saving the model successfully, the controller may redirect the user browser to the model detail page. Note that the actual implementation of saving a model should be located in the model instead of the controller.

• should avoid containing embedded SQL statements, which are better kept in models.

• should avoid containing any HTML or any other presentational markup. This is better kept in views.

In a well-designed MVC application, controllers are often very thin, containing probably only a few dozen lines of code; while models are very fat, containing most of the code responsible for representing and manipulating the data. This is because the data structure and business logic represented by models is typically very specific to the particular application, and needs to be heavily customized to meet the specific application requirements; while controller logic often follows a similar pattern across applications and therefore may well be simplified by the underlying framework or the base classes.

看到cnbeta上这个QQ词典官网上线的时候，我就在想，QQ还有什么是不做的？浩方游戏平台一出，QQ也出了游戏平台，网易出点网游，QQ也出自主网游。搜狗有了输入法，QQ也出了。搜狗出五笔了，QQ也推出了。360有软件管理了，QQ也有了。当然我这里还没有提最早的联众棋牌，是因为现在很多人恐怕都不知道有联众这个软件了吧？你有淘宝我有拍拍，你有百度我有搜搜，你有新浪财经，我有QQ财经。你有。。。我有。。。。，你有啥，我很快就有啥。

上新闻吧。。。

QQ 词典是腾讯公司最新推出的一款桌面词典软件。QQ词典以其清爽的界面、丰富的词库，为您提供海量词汇的丰富解释，包括词语的基本解释、网络解释和例句、百 科等内容。同时，QQ词典强大、灵活的屏幕取词功能，带给您无干扰的全新取词感受。

2010年5月6日，QQ词典1.0Beta1正式新鲜出炉啦！QQ词典在QQ实验室中的官方网站也同步上线，网址为：http://labs.qq.com/labs/qqdict.shtml。

欢迎您下载QQ词典客户端，或者访问QQ词典的在线查询网址http://dict.qq.com/。

在今后的日子里，您将在这里见证QQ词典一步一步的成长。

原文在：http://www.cnbeta.com/articles/110391.htm

正象评论里所说的，QQ或许真的会象雨林木风那样推出自己改过的ubuntu吗？未来是怎么样，还真的难说呀。

以前我一直用金山词霸，现在用有道了，因为我不喜欢金山那种非要通行证登录的功能。而且有道还有一个OCR图片取词，我觉得偶尔使用一下，感觉不错（有道好象现在在手机版上还支持拍照取词，看过演示视频，感觉很强大）

封面放上一张，详细和更多请看详细。

» 阅读全文

Google Analytics一直为各个站长朋友提供着优质免费的服务,今天Google Analytics进行了比较大的更新,新的功能包括自定义报表,受众分析,Adsense分析,开放API,还有一些用户界面的更新.

 

1. 自定义报告: Lets you create reports using any source of data (such as people who have bought something on your site, average number of pageviews, geography, visiting source) as the X and Y coordinates for a chart.

2. 受众分析: Lets you look at custom slices of your Website’s audience (such as people who stay for more than two minutes, people who came from TechCrunch, people who came from the New York Times, people who bought something, people who came from Techcrunch and bought something).

3. Adsense集成: This was along time coming. You can already track how your AdWords campaigns impact traffic to your site. Now you can see data from your AdSense account as well. Marry that with Google Analytics data and you can get new insights into not only which ads you place through AdSense are doing the best, but from which referring sites. (Read more on the AdSense blog).

4. API: This will be rolling out “soon,’ but is also being announced today. Google will open up an API to Gogle Analytics that will allow developers to pipe all of the data in Google Analytics to other Websites, tools, widgets, or even mobile apps. So if someone wants to create a widget that will let people show their Google Analytics charts on their blog, that will be possible.

5. 气泡方式显示图表: The new motion charts allow you to visualize data across five dimensions (x axis, y axis, size of bubble, color of bubble, and position over time). It lets you create an animation to show you what’s been happening with your Website’s key metrics. This feature comes out of the Trendalyzer software Google bought from Gapminder in 2007. (See video below).

6. 用户界面优化: You’ll notice some new subtle shading and highlighting. But the biggest change will be in the management dashboard. Now, if you track more than one Website with Google Analytics, you will be able to see trends across all of them at once.

原文：http://www.cnbeta.com/articles/67788.htm