如:
$sql = “insert into article (`channel_id`,`title`,`detail`,`pub_time`) values (‘{$cid}’,'{$title}’,'{$detail}’,'{$time}’);”;

不加似乎也可以,加{}是什么意思呢?
还有字段名 为什么要以“包括呢?

 

==================================================

 

最佳答案
至少便于阅读嘛~~~''是insert into语句要求的,因为字符串要成对出现嘛
加{}有时候是为了防止变量名和后面的字符串连在一起嘛
例如
{$cid}dd
如果cid=aa
那么{$cid}dd=aadd
不加的话你自己看看了$ciddd,岂不变成了ciddd变量了~~

 

 

PHP变量放在大括号里面的含义

 

 

        

  1. //   The   following   is   okay   as   it’s   inside   a   string.     Constants   are   not        
  2.   //   looked   for   within   strings   so   no   E_NOTICE   error   here        
  3.   print   ”Hello   $arr[fruit]“;             //   Hello   apple        
  4.          
  5.   //   With   one   exception,   braces   surrounding   arrays   within   strings        
  6.   //   allows   constants   to   be   looked   for        
  7.   print   ”Hello   {$arr[fruit]}”;         //   Hello   carrot        
  8.   print   ”Hello   {$arr['fruit']}”;     //   Hello   apple    

下面几个比较能说明原因的解释是:

        

  1. 表示{}里面的是一个变量  ,执行时按照变量来处理    
  2. 在字符串中引用变量使用的特殊包括方式,这样就可以不使用.运算符,从而减少代码的输入量了。

其实输出那块是等同于print   “hello   “.$arr['fruit'];  

 

 

PHP: 字符串变量中大括号(花括号{})的作用

 

PHP 变量后面加上一个大括号{},里面填上数字,就是指 PHP 变量相应序号的字符。
例如:
$str = ‘hello’;
echo $str{0}; // 输出为 h
echo $str{1}; // 输出为 e
如果要检查某个字符串是否满足多少长度,可以考虑用这种大括号(花括号)加 isset 的方式替代 strlen 函数,因为 isset 是语言结构,strlen 是函数,所以使用 isset 比使用 strlen 效率更高。
比如判断一个字符串的长度是否小于 5:
if ( !isset ( $str{5} ) ) 就比 if ( strlen ( $str ) < 5 ) 好。

 
这个小程序一共包含6个文件,其中index.php是程序入口、post.htm是留言表单、在lib文件夹里Model、View 、Controller三个文件分别实现MVC,DataAccess是一个简单的数据库访问类。

复制PHP内容到剪贴板

PHP代码:


<?php
/**
*  一个用来访问MySQL的类
*  仅仅实现演示所需的基本功能,没有容错等
*  代码未作修改,只是把注释翻译一下,加了点自己的体会
*/
class DataAccess {

var $db; //用于存储数据库连接

var $query; //用于存储查询源

//! 构造函数.
/**
* 创建一个新的DataAccess对象
* @param $host 数据库服务器名称
* @param $user 数据库服务器用户名
* @param $pass 密码
* @param $db   数据库名称
*/
function __construct($host,$user,$pass,$db) {
$this->db=mysql_pconnect($host,$user,$pass); //连接数据库服务器
mysql_select_db($db,$this->db);              //选择所需数据库
//特别注意$db和$this->db的区别
//前者是构造函数参数
//后者是类的数据成员
}

//! 执行SQL语句
/**
* 执行SQL语句,获取一个查询源并存储在数据成员$query中
* @param $sql  被执行的SQL语句字符串
* @return void
*/
function fetch($sql) {
$this->query=mysql_unbuffered_query($sql,$this->db); // Perform query here
}

//! 获取一条记录
/**
* 以数组形式返回查询结果的一行记录,通过循环调用该函数可遍历全部记录
* @return mixed
*/
function getRow () {
if ( $row=mysql_fetch_array($this->query,MYSQL_ASSOC) )
//MYSQL_ASSOC参数决定了数组键名用字段名表示
return $row;
else
return false;
}
}
?>

下面再来介绍一下Model类。
这个类也很简单,里面的函数一看就知道,是针对各种数据操作的,它通过DataAccess访问数据库。

复制PHP内容到剪贴板

PHP代码:


<?php
//! Model类
/**
* 它的主要部分是对应于留言本各种数据操作的函数
* 如:留言数据的显示、插入、删除等
*/

class Model {

var $dao; //DataAccess类的一个实例(对象)

//! 构造函数
/**
* 构造一个新的Model对象
* @param $dao是一个DataAccess对象
* 该参数以地址传递(&$dao)的形式传给Model
* 并保存在Model的成员变量$this->dao中
* Model通过调用$this->dao的fetch方法执行所需的SQL语句
*/
function __construct(&$dao) {
$this->dao=$dao;
}

function listNote() {    //获取全部留言
$this->dao->fetch("SELECT * FROM note");
}

function postNote($name,$content) {    //插入一条新留言
$sql = "INSERT INTO `test`.`note`
(`id`, `name`, `content`, `ndate`, `add`)
VALUES (NULL, '$name', '$content', NULL, NULL);";
//echo $sql;  //对于较复杂的合成SQL语句,<br />
//调试时用echo输出一下看看是否正确是一种常用的调试技巧
$this->dao->fetch($sql);
}

function deleteNote($id) {   //删除一条留言,$id是该条留言的id
$sql = "DELETE FROM `test`.`note` WHERE `id`=$id;";
//echo $sql;
$this->dao->fetch($sql);
}

function getNote() {    //获取以数组形式存储的一条留言
//View利用此方法从查询结果中读出数据并显示
if ( $note=$this->dao->getRow() )
return $note;
else
return false;
}
}
?>

看完这两个类之后你可能会发现这与以前我们写程序差不多,的确现在还闻不到MVC的味道,如果你不懂MVC,在这两个类的基础上你完全可以开始写你以前的程序了。例如要显示全部留言,只需要写入下代码:

复制PHP内容到剪贴板

PHP代码:


<?php
require_once('lib/DataAccess.php');
require_once('lib/Model.php');

$dao=& new DataAccess ('localhost','root','','test');
$model=& new Model($dao);
$model->listNote();

while ($note=$model->getNote())
{
$output.="姓名:$note[name]<br> 留言:<br> $note[content] <br> <hr />";
}
echo $output;
?>

很亲切吧,呵呵。
有了这个“感情基础”你就不会对MVC望而生畏了,下面我们就要上今天的主菜了,那就是“Controller”闪亮登场!
先大体浏览一下主要结构,它包括一个Controller类以及派生出的三个子类(listController对应显示留言功能、postController对应发表留言功能以及deleteController对应删除留言功能)。

复制PHP内容到剪贴板
PHP代码:
<?php
//! Controller
/**
* 控制器将$_GET['action']中不同的参数(list、post、delete)
* 对应于完成该功能控制的相应子类
*/

class Controller {
var $model;  // Model 对象
var $view;   // View  对象

//! 构造函数
/**
* 构造一个Model对象存储于成员变量$this->model;
*/
function __construct (& $dao) {
$this->model=& new Model($dao);
}

function getView() {    //获取View函数
//返回视图对象view
//对应特定功能的Controller子类生成对应的View子类的对象
//通过该函数返回给外部调用者
return $this->view;
}

}

//用于控制显示留言列表的子类
class listController extends Controller{   //extends表示继承  

function __construct (& $dao) {
parent::__construct($dao);  //继承其父类的构造函数
//该行的含义可以简单理解为:
//将其父类的构造函数代码复制过来
$this->view=& new listView($this->model);
//创建相应的View子类的对象来完成显示
//把model对象传给View子类供其获取数据
}
}

//用于控制添加留言的子类
class postController extends Controller{

function __construct (& $dao, $post) {
parent::__construct($dao);
$this->view=& new postView($this->model, $post);
//$post的实参为$_POST数组
//表单中的留言项目存储在该系统数组中
}
}

//用于控制删除留言的子类
class deleteController extends Controller{
function __construct (& $dao, $id) {
parent::__construct($dao);
$this->view=& new deleteView($this->model, $id);
}
}
?>

大体浏览之后,你一定打算开始仔细研究它了吧,别急,为了心中有数,我们先从宏观着眼,先看看总入口index.php是如何调用Controller的:

复制PHP内容到剪贴板

PHP代码:

 

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
<title>PHP MVC留言板</title>
</head>
<body>
<a href="post.htm">添加新留言</a><br>
<p>

<?php
//!index.php 总入口
/**
* index.php的调用形式为:
* 显示所有留言:index.php?action=list
* 添加留言    :index.php?action=post
* 删除留言    :index.php?action=delete&id=x
*/
require_once('lib/DataAccess.php');
require_once('lib/Model.php');
require_once('lib/View.php');
require_once('lib/Controller.php');
//创建DataAccess对象(请根据你的需要修改参数值)
$dao=& new DataAccess ('localhost','root','','test');
//根据$_GET["action"]取值的不同调用不同的控制器子类
$action=$_GET["action"];

switch ($action)
{
case "post":
$controller=& new postController($dao,$_POST); break;
case "list":
$controller=& new listController($dao); break;
case "delete":
$controller=& new deleteController($dao,$_GET["id"]); break;
default:
$controller=& new listController($dao); break; //默认为显示留言

}

$view=$controller->getView(); //获取视图对象
$view->display();             //输出HTML
?>
</body>
</html>

看过index.php之后你就更清楚了吧,原来功能是通过$_GET[“action”]指定的,由一个switch结构分发,不同的功能对应不 同的Controller子类。现在可以滚上去(滚动页面上去的简称,绝非不洁用语^_^)仔细看看这个Controller代码了。注释应该很细了,不 懂的地方就去看看PHP5的OOP语法和概念吧,单纯看这些概念总是越看催眠效果越好,现在带着实际问题去看,应该有所不同吧。不过我还是建议你在完成这 个MVC的Hello World知道MVC是怎么回事之后下功夫打好OOP的基础,毕竟那是根本啊。
怎么样,Controller真是个光说不练的家伙吧,看不到三行它就把你引向View了,那就看看View吧。
View里有对应的子类,负责相应功能的显示。理解了Controller,View的代码就不难看了,难看的话也是因为混杂着HTML的原因,它所做的就是从Model获取所需的数据,然后塞到HTML中。

复制PHP内容到剪贴板

PHP代码:


<?php
//! View 类
/**
* 针对各个功能(list、post、delete)的各种View子类
* 被Controller调用,完成不同功能的网页显示
*/
class View {

var $model;  //Model对象

var $output; //用于保存输出HTML代码的字符串

//! 构造函数
/**
* 将参数中的Model对象接收并存储在成员变量$this->model中
* 供子类通过model对象获取数据
*/
function __construct (&$model) {
$this->model=$model;
}

function display() {  //输出最终格式化的HTML数据
echo($this->output);
}
}

class listView extends View   //显示所有留言的子类
{
function __construct(&$model)
{
parent::__construct(&$model);   //继承父类的构造函数(详见Controller)
$this->model->listNote();
while ($note=$this->model->getNote())  //逐行获取数据
{
$this->output.="姓名:$note[name]<br> 留言:<br> $note[content]
<a href=\"".$_SERVER['PHP_SELF']."?action=delete&id=$note[id]\">删除</a><br> <hr />";
}
}
}

class postView extends View  //发表留言的子类
{
function __construct(&$model, $post)
{
parent::__construct(&$model);
$this->model->postNote($post[name],$post[content]);
$this->output="Note Post OK!<br><a href=\"".$_SERVER['PHP_SELF']."?action=list\">查看</a>";
}
}

class deleteView extends View  //删除留言的子类
{
function __construct(&$model, $id)
{
parent::__construct(&$model);
$this->model->deleteNote($id);
$this->output="Note Delete OK!<br><a href=\"".$_SERVER['PHP_SELF']."?action=list\">查看</a>";
}
}
?>

之所以UI方面写得如此简陋,是因为这些工作可以交给Smarty这样的模板去做,而我们这里就像集中精力研究MVC,不想把Smarty扯进来,所以就这样凑合了,以后我们可以再把Smarty结合进来。
看了这个东西之后不知你是否对MVC的概念和实现更明白了一点。
我也是个初学者,这是个依葫芦画瓢之作,目的就是想了解一下MVC,如果你是高手,我很想得到你的点评,这样的划分和架构是否符合MVC的理念?还有哪些应该改进之处?
当然,大家都知道现在很多关于MVC的争论,这很正常,就像关于开发语言的争论一样,永无休止,学术上的争论有助于创新。作为我们学技术、用技术而言,一 定要踏实深入学习,掌握了基本用法之后再去讨论,那才是更高层次的发展,在自己都搞不清的情况下在哪里争论只能是浪费时间。
下面说说我体会到的MVC的好处,它的确给程序的功能扩展带来方便,比如这个例子我们想要增加一个根据用户名查询留言的功能,只需要在Model里增加一 个查询函数(突然发现这些函数的用法很像存储过程),Controller和View里增加相应的子类,这种分离带来的好处是程序功能模块可以即插即用, 再就是整个程序的逻辑非常清晰。我想,对于需求变动频繁的Web应用来说,这种特性也许是很有价值的。

 

 
mvc-rails

原文链接:http://www.cppblog.com/darkdestiny/archive/2009/01/13/71944.aspx

以前一直无法舒坦的理解,MVC模式是怎样实际应用到一个程序上的。

这两天因为工作google出一幅图,然后恍然大悟。

1.

 

问题就出在以前所看过的文章上根本没有提过browser这层。导致我无法正确理解view的责任、controller的责任,以及两者明明是分层的,为什么却是循环依赖。

 

我将browser介入其中,重新思考MVC模式究竟如何部署到程序结构上。

2.

 

计算机前的用户,只会和browser打交道,也就是整个应用程序的界面部署,各种窗口,包括菜单、按钮、子对话框等等。

我把整个界面部署的代码,全部放置到browser模块下。此时无需modelviewcontroller,仅有browser的代码,我们就可以给用户显示这个界面。

 

接下来我引入model模块,这个模块的代码和窗口无关、和控件无关、和HWND无关。就是一个后台运行的东西,不需要面向任何用户。

model包含了业务的本质数据结构和逻辑流程。

 

然后我引入view模块,view模块代码的责任就是,如何利用browser显示model的内容。

这个责任有两个潜在意义:

  1. 1.       browser模块的代码不会去访问model模块的内容,并显示在browser相应的窗口上。
  2. 2.       在没有controller的情况下——用户不能操作程序界面上的任何菜单、按钮,只能看不能摸,view模块能够在browser上给用户显示model的内容。

因此,view模块在MVC模式中所能做的就是:

  1. 1.       访问model模块,获取内容。
  2. 2.       访问browser模块,修改窗口。

 

最后引入controller模块。

用户在计算机前看着browser,浏览业务数据,他肯定会做一些操作,比如按下按钮,选个菜单或者其他什么的。

用户修改model模块的每一个决定性操作,就映射在controller模块的一个接口上。controller模块的责任是,代表用户的每一个动作,并分解为多个view做什么,model做什么的调用。这个动作必须有操作model或者view的代码,不然这个动作放在browser模块下就可以了。

 

现在合起来分析个例子,用户通过browsermodel添加一个任务。

按下确定按钮后,browser读取其他子窗口的输入数据,当做参数传递给controller模块对应的调用。

controller模块不会主动的从browser中的控件中读取数据。如果用户的动作足够简单,controller有可能就仅仅作为一个中间层调用model模块。

 

controller模块将用户的动作分解为一些更细致的调用:

  1. 1.       让model添加新任务。(不关心model怎么做)
  2. 2.       从model中获取新任务的信息。
  3. 3.       将新任务的信息传递给view,让他在browser显示出来。(不关心view怎么做)

 

controller的动作分解中可以看出:

l  和之前view直接访问model获取数据不一样,这里controllermodel获取数据,并交给view。仅由controller访问model是有好处的,使得viewmodel没有了耦合。

l  这里有一个微妙的循环依赖关系,browser依赖于controllercontroller依赖于viewview又依赖于browser

l  解开这一依赖的方法1,提取一个view interface,让controller依赖于他,而不是依赖于view。提取controller interface也是同理。

l  方法2controller不依赖于view,让view自己负责根据model的状态改变显示,即controller负责修改modelview负责读取model

l  不过,viewmodel之间通过controller传递数据是有好处的,除了耦合之外,另一个关键的地方是,可以在controller中过滤数据,而不用修改model

l  这两个方法没有最好,只有根据具体的情况选择最合适的做法。在程序足够小的情况下,其实是不需要把模块划分得那么清楚的。

 

O(_)O

 

 

文章来源:http://www.cnblogs.com/qiantuwuliang/archive/2010/03/05/1679174.html

Continue reading »

 

转载说明:在看程序代码过程中,有类似@param的东东,看不懂什么意思,这篇文章对程序代码的注释规范做了比较系统的整理,有参考价值。虽然是写JAVA的,但PHP也应该可以用吧。

文章原文网址:http://gyhgc.iteye.com/blog/225039

Orange

在软件开发的过程中总是强调注释的规范,但是没有一个具体的标准进行说明,通常都是在代码编写规范中简单的描述几句,不能作为一个代码注释检查的标准和依据,做什么都要有一个依据吗:),现在我特整理了一个《Java的注释规范》,内容来自网络、书籍和自己的实际积累。
JAVA注释规范

版本/状态 作者 版本日期
1.0 ghc 2008-07-02

一、背景
1、当我们第一次接触某段代码,但又被要求在极短的时间内有效地分析这段代码,我们需要什么样的注释信息?
2、怎么样避免我们的注释冗长而且凌乱不堪呢?
3、在多人协同开发、维护的今天,我们需要怎么样的注释来保证高质、高交的进行开发和维护工作呢?
二、意义
程序中的注释是程序设计者与程序阅读者之间通信的重要手段。应用注释规范对于软件本身和软件开发人员而言尤为重要。并且在流行的敏捷开发思想中已经提出了将注释转为代码的概念。好的注释规范可以尽可能的减少一个软件的维护成本 , 并且几乎没有任何一个软件,在其整个生命周期中,均由最初的开发人员来维护。好的注释规范可以改善软件的可读性,可以让开发人员尽快而彻底地理解新的代码。好的注释规范可以最大限度的提高团队开发的合作效率。长期的规范性编码还可以让开发人员养成良好的编码习惯,甚至锻炼出更加严谨的思维能力。
三、注释的原则
1、 注释形式统一
在整个应用程序中,使用具有一致的标点和结构的样式来构造注释。如果在其他项目组发现他们的注释规范与这份文档不同,按照他们的规范写代码,不要试图在既成的规范系统中引入新的规范。
2、 注释的简洁
内容要简单、明了、含义准确,防止注释的多义性,错误的注释不但无益反而有害。
3、 注释的一致性
在写代码之前或者边写代码边写注释,因为以后很可能没有时间来这样做。另外,如果有机会复查已编写的代码,在今天看来很明显的东西六周以后或许就不明显了。通常描述性注释先于代码创建,解释性注释在开发过程中创建,提示性注释在代码完成之后创建。修改代码的同时修改相应的注释,以保证代码与注释的同步。
4、 注释的位置
保证注释与其描述的代码相邻,即注释的就近原则。对代码的注释应放在其上方相邻或右方的位置,不可放在下方。避免在代码行的末尾添加注释;行尾注释使代码更难阅读。不过在批注变量声明时,行尾注释是合适的;在这种情况下,将所有行尾注释要对齐。
5、 注释的数量
注释必不可少,但也不应过多,在实际的代码规范中,要求注释占程序代码的比例达到20%左右。注释是对代码的“提示”,而不是文档,程序中的注释不可喧宾夺主,注释太多了会让人眼花缭乱,注释的花样要少。不要被动的为写注释而写注释。
6、删除无用注释
在代码交付或部署发布之前,必须删掉临时的或无关的注释,以避免在日后的维护工作中产生混乱。
7、 复杂的注释
如果需要用注释来解释复杂的代码,请检查此代码以确定是否应该重写它。尽一切可能不注释难以理解的代码,而应该重写它。尽管一般不应该为了使代码更简单便于使用而牺牲性能,但必须保持性能和可维护性之间的平衡。
8、 多余的注释
描述程序功能和程序各组成部分相互关系的高级注释是最有用的,而逐行解释程序如何工作的低级注释则不利于读、写和修改,是不必要的,也是难以维护的。避免每行代码都使用注释。如果代码本来就是清楚、一目了然的则不加注释,避免多余的或不适当的注释出现。
9、必加的注释
典型算法必须有注释。在代码不明晰或不可移植处必须有注释。在代码修改处加上修改标识的注释。在循环和逻辑分支组成的代码中添加注释。为了防止问题反复出现,对错误修复和解决方法的代码使用注释,尤其是在团队环境中。
10、注释在编译代码时会被忽略,不编译到最后的可执行文件中,所以注释不
会增加可执行文件的大小。
四、JAVA注释技巧
1、空行和空白字符也是一种特殊注释。利用缩进和空行,使代码与注释容易区
别,并协调美观。
2、当代码比较长,特别是有多重嵌套时,为了使层次清晰,应当在一些段落的
结束处加注释(在闭合的右花括号后注释该闭合所对应的起点),注释不能
写得很长,只要能表示是哪个控制语句控制范围的结束即可,这样便于阅读。
3、将注释与注释分隔符用一个空格分开,在没有颜色提示的情况下查看注释时,
这样做会使注释很明显且容易被找到。
4、不允许给块注释的周围加上外框。这样看起来可能很漂亮,但是难于维护。
5、每行注释(连同代码)不要超过120个字(1024×768),最好不要超过80
字(800×600) 。
6、Java编辑器(IDE)注释快捷方式。Ctrl+/ 注释当前行,再按则取消注释。
7、对于多行代码的注释,尽量不采用“/*……*/”,而采用多行“//”注释,
这样虽然麻烦,但是在做屏蔽调试时不用查找配对的“/*……*/”。
8、注释作为代码切换开关,用于临时测试屏蔽某些代码。
例一:
//*/
codeSegement1;
//*/
改动第一行就成了:
/*/
codeSegement1;
//*/
例二:
//———————-第一段有效,第二段被注释
//*/
codeSegement1;
/*/
codeSegement2;
//*/
只需删除第一行的/就可以变成:
//———————-第一段被注释,第二段有效
/*/
codeSegement1;
/*/
codeSegement2;
//*/
五、JAVA注释方法及格式
1、单行(single-line)–短注释://……
单独行注释:在代码中单起一行注释, 注释前最好有一行空行,并与其后的代码具有一样的缩进层级。如果单行无法完成,则应采用块注释。
注释格式:/* 注释内容 */

行头注释:在代码行的开头进行注释。主要为了使该行代码失去意义。
注释格式:// 注释内容

行尾注释:尾端(trailing)–极短的注释,在代码行的行尾进行注释。一般与代码行后空8(至少4)个格,所有注释必须对齐。
注释格式:代码 + 8(至少4)个空格 + // 注释内容
2、块(block)–块注释:/*……*/
注释若干行,通常用于提供文件、方法、数据结构等的意义与用途的说明,或者算法的描述。一般位于一个文件或者一个方法的前面,起到引导的作用,也可以根据需要放在合适的位置。这种域注释不会出现在HTML报告中。注释格式通常写成:
/*
* 注释内容
*/
3、文档注释:/**……*/
注释若干行,并写入javadoc文档。每个文档注释都会被置于注释定界符
/**……*/之中,注释文档将用来生成HTML格式的代码报告,所以注释文
档必须书写在类、域、构造函数、方法,以及字段(field)定义之前。注释文档由两部分组成——描述、块标记。注释文档的格式如下:
/**
* The doGet method of the servlet.
* This method is called when a form has its tag value method
* equals to get.
* @param request
*  the request send by the client to the server
* @param response
*  the response send by the server to the client
* @throws ServletException
*  if an error occurred
* @throws IOException
*  if an error occurred
*/
public void doGet (HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
doPost(request, response);
}
前两行为描述,描述完毕后,由@符号起头为块标记注释。更多有关文档注
释和javadoc的详细资料,参见javadoc的主页: http://java.sun.com/javadoc/index.html
4、javadoc注释标签语法
@author    对类的说明 标明开发该类模块的作者
@version   对类的说明 标明该类模块的版本
@see      对类、属性、方法的说明 参考转向,也就是相关主题
@param    对方法的说明 对方法中某参数的说明
@return    对方法的说明 对方法返回值的说明
@exception  对方法的说明 对方法可能抛出的异常进行说明
六、JAVA注释具体实现
1、源文件注释
源文件注释采用 /** …… */,在每个源文件的头部要有必要的注释信息,包括:文件名;文件编号;版本号;作者;创建时间;文件描述包括本文件历史修改记录等。中文注释模版:
/**
* 文 件 名 :
* CopyRright (c) 2008-xxxx:
* 文件编号:
* 创 建 人:
* 日    期:
* 修 改 人:
* 日   期:
* 描   述:
* 版 本 号:
*/

2、类(模块)注释:
类(模块)注释采用 /** …… */,在每个类(模块)的头部要有必要的注释信息,包括:工程名;类(模块)编号;命名空间;类可以运行的JDK版本;版本号;作者;创建时间;类(模块)功能描述(如功能、主要算法、内部各部分之间的关系、该类与其类的关系等,必要时还要有一些如特别的软硬件要求等说明);主要函数或过程清单及本类(模块)历史修改记录等。
英文注释模版:
/**
* CopyRright (c)2008-xxxx:   <展望软件Forsoft >
* Project:                     <项目工程名 >
* Module ID:   <(模块)类编号,可以引用系统设计中的类编号>
* Comments:  <对此类的描述,可以引用系统设计中的描述>
* JDK version used:      <JDK1.6>
* Namespace:           <命名空间>
* Author:        <作者中文名或拼音缩写>
* Create Date:  <创建日期,格式:YYYY-MM-DD>
* Modified By:   <修改人中文名或拼音缩写>
* Modified Date:  <修改日期,格式:YYYY-MM-DD>
* Why & What is modified  <修改原因描述>
* Version:                  <版本号>
*/
如果模块只进行部分少量代码的修改时,则每次修改须添加以下注释:
//Rewriter
//Rewrite Date:<修改日期:格式YYYY-MM-DD> Start1:
/* 原代码内容*/
//End1:
将原代码内容注释掉,然后添加新代码使用以下注释:
//Added by
//Add date:<添加日期,格式:YYYY-MM-DD> Start2:
//End2:
如果模块输入输出参数或功能结构有较大修改,则每次修改必须添加以下
注释:
//Log ID:<Log编号,从1开始一次增加>
//Depiction:<对此修改的描述>
//Writer:修改者中文名
//Rewrite Date:<模块修改日期,格式:YYYY-MM-DD>

2、接口注释:
接口注释采用 /** …… */,在满足类注释的基础之上,接口注释应该包含描述接口的目的、它应如何被使用以及如何不被使用,块标记部分必须注明作者和版本。在接口注释清楚的前提下对应的实现类可以不加注释。

3、构造函数注释:
构造函数注释采用 /** …… */,描述部分注明构造函数的作用,不一定有块标记部分。
注释模版一:
/**
* 默认构造函数
*/
注释模版二:
/**
* Description :       带参数构造函数,
*                       初始化模式名,名称和数据源类型
* @param schema:   模式名
* @param name:   名称
* @param type: 数据源类型
*/

4、函数注释:
函数注释采用 /** ……*/,在每个函数或者过程的前面要有必要的注释信息,包括:函数或过程名称;功能描述;输入、输出及返回值说明;调用关系及被调用关系说明等。函数注释里面可以不出现版本号(@version)。
注释模版一:
/**
* 函 数 名 :
* 功能描述:
* 输入参数:     <按照参数定义顺序>
*             <@param后面空格后跟着参数的变量名字
*            (不是类型),空格后跟着对该参数的描述。>
*
* 返 回 值:  – 类型 <说明>
*            <返回为空(void)的构造函数或者函数,
*            @return可以省略; 如果返回值就是输入参数,必须 *            用与输入参数的@param相同的描述信息; 必要的时*            候注明特殊条件写的返回值。>
* 异    常:<按照异常名字的字母顺序>
* 创 建 人:
* 日    期:
* 修 改 人:
* 日    期:
*/
注释模版二:
/**
* FunName:           getFirstSpell
* Description :      获取汉字拼音首字母的字符串,
*                   被生成百家姓函数调用
* @param:         str the String是包含汉字的字符串
* @return String:汉字返回拼音首字母字符串;
*                  英文字母返回对应的大写字母;
*                 其他非简体汉字返回 ’0′;
* @Author:       ghc
* @Create Date: 2008-07-02
*/

5、方法注释:
方法注释采用 /** …… */,对于设置 (Set 方法 ) 与获取 (Get 方法 ) 成员的方法,在成员变量已有说明的情况下,可以不加注释;普通成员方法要求说明完成什么功能,参数含义是什么且返回值什么;另外方法的创建时间必须注释清楚,为将来的维护和阅读提供宝贵线索。

6、方法内部注释:
控制结构,代码做了些什么以及为什么这样做,处理顺序等,特别是复杂的逻辑处理部分,要尽可能的给出详细的注释。

7、 全局变量注释:
要有较详细的注释,包括对其功能、取值范围、哪些函数或者过程存取以及存取时注意事项等的说明。

8、局部(中间)变量注释:
主要变量必须有注释,无特别意义的情况下可以不加注释。

9、实参/参数注释:
参数含义、及其它任何约束或前提条件。

10、字段/属性注释: 字段描述,属性说明。

11、常量:常量通常具有一定的实际意义,要定义相应说明。

 

汉语中,board, committee, commission 及 council这几个辞汇都可以翻译成“委员会”,看不出区别。单独在一起的时候,是没有问题的,不会引起混乱。可是一旦在英文文件中,这几个类型的委员 会出现并列的时候,若都翻译成委员会,就容易引起混淆了,难以区分不同的组织类型,从而丧失英文语境中本来应该有的涵义。如在威尔米特区的托管委员会下 (village board of trustees),有boards, 包含building code board of appeals、emergency telephone system、fire pension board等;有commissions, 如appearance, community relations, electrical等;还有committees, 如administration, finance, intergovernmental cooperation等。在这种情况下,如果一概翻译成委员会,肯定是不妥当的。
在英语中,board关于委员会的涵义是“an organized body of administrators or investigators”,即由一群管理者或者调查人员组成的团体。而council指的是a body of people elected or appointed to serve in an administrative legislative, or advisory capacity, 即选出或者委派的行使行政、司法和协商功能的团体。单纯从解释来看,也看不出来差别。但从美国语境中,board一般指的是有一群管理者 (director)组成的团体,每一个管理者关注的是整个组织的利益,board里一般有个起领导作用的成员(president)。相对而 言,council的成员往往代表不同区域或者团体的利益,成员之间的关系往往更民主,没有起领导作用的特殊成员的存在。
而commission在英文指的是“a group of people officially authorized to perform certain duties or functions”,即“官方授权承担某项责任或者职能的一群人”。以正式程度来说,显然board与council更为正式些。commission 执行的是某一项特定的责任或者职能,比较常规的任务。而committee在英文中指的是“a group of people officially delegated to perform a function, such as investigation, considering, reporting, or acting on a matter”,从字面意思看,也是指的是“受官方委托履行一种职能的一群人,如对事情靠察、研究、报告或者采取行动”。但committee往往更具临 时性质。有的组织在commission下面设committee。如联合国和平建设委员会(peacebuilding commission)下设organizational committee 及 country-specific committees。
综上,似乎board译为管理委员会,council译为代表会,commission译为委员会,committee译为临时委员会为宜。

 

转载来源:http://blog.sina.com.cn/s/blog_4175f73f0100eku8.html

 

因为PHP是一个Web编程语言,在编程过程中难免会遇到用echo来输出大段的html和javascript脚本的情况,如果用传统的输出方法 ——按字符串输出的话,肯定要有大量的转义符来对字符串中的引号等特殊字符进行转义,以免出现语法错误。如果是一两处还可以容忍,但是要是一个完整的 html文本或者是一个200行的js我想是谁都会崩溃的。这就是PHP为什么要引入一个定界符的原因——至少一大部分原因是这样的。

1.PHP定界符的作用就是按照原样,包括换行格式什么的,输出在其内部的东西;
2.在PHP定界符中的任何特殊字符都不需要转义;
3.PHP定界符中的PHP变量会被正常的用其值来替换。
PHP中的定界符格式是这样的:
<<<Eof
……
Eof;
看起来很简单,但是其中有许多地方需要注意。
首先在<<<之后的字符Eof是自己定义的,随便什么都是可以的(比如AAA都可以),但是结尾处的字符一定要和他一样,他们是成对出现的,就像{}这样的——这是最基本的。
在PHP定界符使用的过程中,第二个需要注意的问题——也是最经常出现问题的地方:
结尾的一行(如上例的Eof;),一定要另起一行,并且改行除了Eof;这个定界符结尾标识之外不能有任何其他字符,前后都不能有,包括空格。如果在本行最前或者最后出现空格,制表符的话,你会收到一个这样的错误信息:
Parse error: parse error, unexpected $end in……,提示你语法错误;
第三个需要注意的是,如果在定界符中间出现有PHP的变量,你只需要像在其它字符串中输出一样写就行了,例如
<<<Eof
hello{$name}
Eof;
变量$name之所以要用{}括起来是要告诉PHP解析器这是一个PHP变量,其实不用也是可以的,但是有可能会产生歧义,例如你的变量后面刚好不是一字母或者特殊符号什么的会怎么样呢?千万不能有这样的写法
<<<Eof
hello<?php echo $name?>
Eof;
这样的情况,你同样会收到一个语法错误的信息。先便是一个战地测试过的PHP定界符的正确写法。里面包含了,html和javascript的代码:
<?php
$name = ‘kitty’;
echo <<<Eof
<table height=”20″>
<tr><td>
{$name}<br/>
<script>
var p=’hello world’;
document.writeln(p);
</script>
</td></tr>
</table>
Eof;
?>

 

文章来源:http://blog.xiqiao.info/2011/10/07/1110

一个活着就是为了去改变世界的天才,在他的巅峰时代离开了这个世界。从普通人到媒体到政治家都关注他的离去。Google在首页上致以数位时代所能表达的最大敬意,老乔也算哀荣无限了。他完全衬得上这一切荣耀。能拥有他,是这个时代的幸运。

这篇潦草的提纲是为新京报而作,登载在今日发刊的悼念Jobs的专题上。有删节。现登出全稿,向这个时代最伟大的产品设计师致以我的敬意。

Virushuo 今天也发了 BLOG:Think different & be yourself 缅怀乔布斯

──────────────────────────────────────────────────────────────────────────────

质量:

重视细节:从产品的选材,设备圆角的弧度,边缘的手感,精妙的icon设计,到看不见的底层效率、甚至包括灯光亮度颜色不那么重要的小角色都经过高标准和严谨的设计,力求每一个细节都能保持水准,并与整体协调。

MBP、AIR、Mini 等设备的外型无论从哪个角度看都很优雅和漂亮,这得益于对圆角弧度的精确设计,和使用自由曲线圆角的MacBook Unibody相比,MBP的曲面更平缓,形成柔和过渡的高光带,同时拥有锐利的边角线,可以产生分割明显的明暗对比。

iPhone 上icon的设计,方寸之间,细节非常到位,比如备忘录的icon上可以看到便签纸被撕去所残留下的边缘。指南针icon的设计中,精细地刻画出360个刻度。

 

永远追求创新:主打产品的每一代都有着能领导行业的革命性的变化,如Touch 开始使用的多点触摸技术,iPhone4开始使用的Retina屏幕及超长待机时间,Macbook Pro的Unibody机身 等等

永不放低标准:为了提高毫秒级别的交互反馈速度或毫米级别的设备尺寸,而不惜开发时间及成本上的代价,不惜等待,不惜使用昂贵及供应不上的原料,不惜折磨设计/工程师。

在iPhone4的侧面的金属天线,有一道黑色的接缝。据说乔布斯当初对这道接缝很不满意,认为不够完美,要求工程师想办法重新设计,避免这道黑色接缝。虽然工程师忙了几个月,最终还是失败了。(据说这是产生天线门的部分原因)关于乔布斯对iphone4在重量和厚度上的苛刻要求而衍生出的段子也很多。

专注:

简洁:简洁是苹果被认识最为普遍的美学特点。但苹果的简洁并不是为了一种审美上的风格而所为,这也是我把它归在专注之下原因。是因为需要做出专注设计,和能让用户专注地进行使用(无论是设备还是设备上的程序/应用/工作环境等,简洁才成为苹果的选择。简洁让用户在使用的时候不被打扰,减少犯错误的机会,降低学习成本,同时在使用它的产品时,能保持优雅与从容的姿态。

iPhone和iPad上只有一个Home键,这是简洁特点的最好体现。

功能的专注:如果一个功能可有可无,它会被砍掉;如果还没有想好该到底该怎么设计,它会被砍掉;如果设计得不够完美(没有达到产品的整体水准或不符合产品气质)它会被砍掉。苹果的美学准则里,并不是简单的功能追随形式或者追随功能,它追求的是一种平衡、有效。尽管这造成了一些暂时的功能缺失,并招致许多辱骂。

最早的iPhone不能复制粘贴,没有多任务。不能复制粘贴是因为没有找到好的操作方式,没有多任务是当时受制于电池技术和CPU性能,提供多任务会让用户体验不流畅,所以干脆砍掉。

偏执:专注到了一定级别会演变为偏执。你可以将这里的偏执理解为“只讲原则”,苹果能成为今天这样,得益于它的偏执。Apple可能是美国唯一一家不做用户调研的大型公司,不做焦点小组讨论,不做问卷分析,只遵循自己的想法做下去。
没有多余的按钮、配件及装饰,即便这些零碎可以讨好一部分用户。我相信苹果并不会因为乔布斯的去世而就此崩溃,但苹果的产品气质的确是由乔布斯塑造的。他所采用的独断的责任制,保证设计原则的彻底贯彻,产品气质的统一完整。其它的设计师也不用担心责任问题(当设计师在无法决定的时候就采取用户调查,并不一定会带来正确的结果,而往往成为逃避思考和推卸责任的方式。)

据说乔布斯会亲自参与设计的苹果专利超过300项,从系统界面到包装到专卖店中装饰。他甚至对产品内部电路板的整齐和美观程度都有要求。是一个理想的完美主义者。他拒绝在苹果设备上设计扩充槽,以支持用户自定义设备,甚至不允许用户更换电池,因为这样就不能产生一个完美而闭合的产品

可用性:

真正重视可用性,重视产品。但是它们重视可用性的方式和其他许多公司都不一样。苹果为用户设计和创造最好的环境及方式,为用户们着想,但并不是讨好他们。用户或者统计数据并不一定能带来正确的选择,只是人们认为那是自己想要的选择(还是相对的)

最初汽车里是没有茶杯座,设计部分做用户调查的时候,用户们纷纷回答:“汽车是用来开的,不是用来喝咖啡的,只有吊车或卡车司机才在车里喝咖啡。” 但当带有茶杯座的汽车款型上市后,很快人们意识到它的价值,这一项内饰设计甚至成为决定销量的武器。在facetime诞生之前,你去问用户,你希望手机上有视频通话功能么,人们多半会回答你那是一个鸡肋。但是iPhone4成功地以facetime为亮点推出了,一是在通话质量、视频时间、移动性和开放性上有了突破(支持wifi),第二是它设计的是一种使用情境和使用方式,而非一项功能。

文中所说的重视细节,质量,简洁,专注等等都是为了其可用性而考虑。

上手容易,无新手门槛。对于一个刚刚接触iPad,iPhone的用户,无论是老人,小孩,甚至猫咪(我家猫咪会玩iPad上专为它们设计的游戏),都能凭直觉去无障碍地使用,甚至他们完全不知道自己在用的是一个高科技的设备。

苹果多个设备间的迁移成本低。比如iMac和苹果标准键盘尺寸和笔记本是完全一样的,对比pc键盘缺少了小键盘和大量辅助按键,但用户在台式机和笔记本切换的时候键盘的体验是一致的。而不像google的Nexus系列,两代之间,基本的4个操作键的排列顺序都不一样

包容性强。因其简洁,也带来强的包容性,即使未掌握部分操作上的小技巧,新手在会使用苹果产品时也不会有障碍。同时对于熟练用户,也提供了空间。

iPhone 上有许多小的操作技巧,比如在输入界面长按输入法切换键,可以直接弹出输入法选择列表,比如MBP左侧面有一个按钮,让你可以无须打开机器就查看剩余电量。而电量是用一排针眼大的小灯来表示的,非常精致。

 

这些小的操作技巧,苹果都没有提供说明书。

苹果的大部分设备都没有说明书,是因为用户不需要学习就能够开始使用,但在使用过程中,用户会慢慢发现这些技巧。这降低了用户的一开始学习成本和使用门槛,同时也基于苹果在产品设计上所具备的直观性。

同时对于熟练用户,苹果提供了好用的快捷键,部分快捷键在所有应用程序(包括第三方开发的)都是统一的。保证了用户在进行快捷操作时能够完整而规范环境。而Window上快捷键确是各自为战,甚至有所冲突的。

 

文章来源:http://blog.devep.net/virushuo/2011/10/07/think_different_be_yourself.html

同时用此文参加imeigu的征文,首先发在imeigu:http://my.imeigu.com/5579705651/20416146

 

另外,arthur369 也写了 Apple产品的美学特征 ──缅怀乔布斯
———————————————

关于苹果几乎每天都在有人谈及,分析苹果的文章也四处都是,在这里我想写一些不一样的,这些在我看来更接近苹果精神的。这些精神我认为源自乔布斯,在前面的许多年中也只有他能守护,以他那种被八卦周刊们称做”人品差”(其实我很怀疑这只是因为他对记者和媒体太不友好,大家玩命黑他)的那种独裁、固执的方式守护。在苹果公司网站上缅怀乔布斯的文字中,最后一句是”Steve留下了一家唯有他才能创建的企业”,正是如此。

苹果不是奢侈品,这一点经常被误传。当然苹果产品确实不便宜,但考虑其质量,往往是市场上能买到最划算的。苹果并不想做市场上最便宜的产品,价格战是最落后的方式,找到理念相合的用户群,并扩大之,这才是好的竞争方式。这个战略在今天看来非常成功,因为电子产品整体成本下降很多,生产成本也下降很多(感谢中国的世界工厂),而经济比90年代有大幅增长,这让现在的苹果产品看起来更容易接受了。在80年代苹果最糟糕的日子里面,这个策略不成功,x86架构的廉价计算机比精心设计的苹果实在便宜太多了,所以更受欢迎。对比当年,今天看来一台苹果笔记本和其他品牌的价格差距更容易被人们接受,而苹果产品细致美观让人们更接受这点价格差距。

不指望做最便宜的产品,才能做出来好的产品。因为一些努力都有对应的成本,尤其是硬件产品。但对应价格的产品质量必须要足够好。苹果产品关注细节,这些细节可能不会被用户非常直接感受到,但总体上会给人舒服的感觉。人的感官比我们所知道的更精细,一些我们并没有注意到的细节会改变最终感受。这种变态追求细节体现在所有地方,当你放大苹果软件和系统中的图标,通常会能感受到变态的细致。比如Mail程序图标上的邮戳,放大之后可以看到HELLO FROM CUPERTINO CA字样,这是来自苹果总部所在地的问候,放大Java设置的图标,你能看到咖啡杯图标中靠近边缘的气泡,正如我们在现实中的一杯真正的咖啡,放大Document Set图标,会看到那一摞书的书脊上都有书名。就算是在今天,苹果各种理念已经深入人心,在非苹果平台上也很难找到如此精细的产品。而人们平时并不太注意这些精细,只是觉得很舒服。这些成本花费是否有意义?我想答案是确定的,这就是乔布斯挑剔精神的体现。好的产品不应该让人能轻松列出各种好处,而是成为一个整体让人感觉很舒服。对于一个不那么特立独行和偏执的企业,降低成本始终是大事(想想现在的丰田汽车就明白了),能够不再乎成本一心追求产品质量,在这个时代已经是非常不容易。如果不是乔布斯这样偏执而天才的领导人,对于职业经理人来说,恐怕难以下定如此决心,更难获得董事会支持。

 

 

苹果产品并不完美,甚至有很多功能缺失。经常会有人对我说,你看苹果没有这个功能,没有那个功能。苹果的理念之一就是如果这个功能不能完美解决,那么就干脆砍掉,如果不能完美升级,那么干脆保持原状。这又是一个和传统观念相悖的做法,一般人们会认为”不完善比没有强”,苹果彻底相反,不完善不如干脆没有。这种理念带来的好处是简化了复杂度,复杂度又和时间相关,按照这样的理念,控制功能需求,就可以在固定时间内提供完成度更好的产品。对于现代软件工程和硬件工程,最大的问题是复杂度难以控制,而难以控制的复杂度会导致产品研发周期变长,投入成本不可控,随后在量产过程,售后支持环节都带来更多不可预测的成本支出。做减法简直是必须的,但大家都知道做减法很难。从苹果的历史看来,乔布斯一直擅长做这件事,不仅在产品上,在企业管理上也一样。他回归苹果之后,在很短时间内砍掉大量非核心业务,让公司终于能顺利生存。随后集中精力在iPod,对于一个制造计算机和服务器的公司,专心去做一个MP3播放器,听起来很可笑,当时也有很多人甚至员工认为很可笑。这个MP3也没有什么伟大创新,只是更好用。最终这个产品成功了,随后才有今天的一切。

今天的苹果产品仍然这样,想想iPhone刚刚出世时,人们诟病什么?不能复制粘贴,单任务,不支持”流行的”Flash,不能换电池…,其实到今天还可以随便找出来iPhone一堆缺点。就算这些缺点存在,苹果的产品仍然变得流行,人们喜欢他们,而不太在意这些缺点,因为苹果提供了更重要的东西,大屏幕,多点触摸,传感器,一个真正的浏览器,方便的音乐播放和购买,优美坚固的外形…我们今天回头来看这些诟病,几乎都能揣测出来一些道理,单任务是因为硬件性能不够,无法保证流畅切换任务和并行运行(想想同时代的nokia多任务),不支持Flash是因为太消耗性能,不能换电池是因为增加可换电池仓增加成本和设计难度…能做这样的减法,不仅需要对用户和市场有足够了解,也需要对开发产品团队和供应链有足够了解。否则他怎么能知道什么可以减少,什么可以在未来版本中支持,什么永不妥协,什么必不可少?这些,乔布斯做到了。在功能、成本、时间中的妥协,寻找平衡,这是伟大的艺术。

我更愿意把乔布斯看作艺术家和精神领袖,他不是工程师也不是Geek。苹果从来不用复杂的名词描述产品,苹果的产品系列也很简单。你只需选择笔记本的尺寸,随后就只有高低两种配置,你无需了解手机的CPU,你只需选择存储大一点或小一点。在买苹果产品这件事上,用户只要知道自己想要什么就可以完成,而无需成为专家。在其他领域你可没这么幸运,无论是买计算机,买手机,买汽车买房子装修,在苹果之外的任何产品,你都先要把自己变成专家,然后才能选出来你需要的东西。简单就是美。简单的精神有体现在苹果的各处,无论是使用产品还是使用网站,获得支持还是培训,都很简单。甚至苹果的发布会,开发者会议,演讲者都使用简单的语言。有朋友笑称去参加苹果会议不用怕英语不好,他们用的单词都是初中生也能听懂的。除了少数Geek用户和专业用户,大多数人更愿意使用简单的东西。不仅在硬件上,软件也一样。在苹果系统中,不用考虑硬盘分区,只需按照用途放在对应目录即可,不用创建复杂的层叠目录用来存放文件,只需搜索即可。这种简单同样体现在苹果提供的网站服务上,iTunes Music Store发布于唱片工业和盗版战争最激烈的时代,那时候P2P下载音乐已经非常普及,多数人不太在意音质,他们会下载MP3然后刻成CD放在车上听(中国共享软件的前辈周奕在网上把MP3刻录CD软件卖给美国用户,赚了大钱)。iTunes Music Store提供了简单的界面,购买方式,简单的价格体系和使用规则,一上线就受到欢迎,前18小时卖掉了275,000 首,前5天卖掉1,000,000首,这个成绩证明了只要足够方便简单,用户愿意付钱购买音乐,几年之后他们更是干脆连DRM保护都去掉了(感谢EMI的大胆尝试),最终成就了今天最大的数字影音产品购买市场,这个辉煌延续到了今天的AppStore。在未来iCloud发布之后,你甚至可以把自己下载的MP3通过Match服务,交很少的钱,一次购买版权,这也足够简单吧?我相信多数人愿意花这笔钱。如何让产品变得简单,如何让一般人更容易理解,这是乔布斯擅长的。对比前几天的iPhone 4S发布会Tim Cook的演讲,是否觉得不如以往乔布斯演讲那么通俗易懂?Tim还没能和乔布斯一样驾驭内容,让演讲做沟通一般用户和产品的桥梁,他还需要更多时间。

乔布斯不是技术专家,也不是工程专家,但他有选择好的技术产品的能力。这也是一个卓越公司领导人必备的能力。在离开苹果,创建NeXT那段时期中,他奠定了今天苹果的技术基础。几个重要技术关头,他都选中了最好的产品,比如,操作系统上拥抱UNIX,这样才有之后转向Intel CPU的能力,也有了iOS使用ARM的能力,开发工具使用了Objective-C,当时的潮流是C++,今天在iOS和OS X开发上,我们亲自体验到了采用Objective-C而不是C++的好处,再比如选择在KHTML基础上创建webkit做为浏览器内核,今天移动设备上webkit已经成了浏览器的标准内核,android浏览器也同样基于此。更底层的还有放弃GCC投资LLVM编译器,这样给予开发者更多特性,帮助他们完成质量更高的应用。最重要的系统和开发工具是在距离今天非常遥远90年代初,在乔布斯离开苹果开办NeXT时做出的选择,实在不得不佩服他超越时代的技术判断力与直觉。

如果让我继续写下去,这篇文章还能写非常长。不过我决定就此结束。苹果的精神难以用语言阐述,需要用心体会。我的朋友 @soulhacker在twitter上“我对 Steve Jobs 最感恩之处在于他无可辩驳的证明了:特立独行、理想主义、完美主义、执着创新是可以成功的,并用他自己的三段人生经历教给我们如何与实用主义及商业社会良好的妥协”,这是我在这几天见到对苹果精神和乔布斯本人最好的概括。

乔布斯的离去一定会对苹果造成影响,从艺术家乔布斯到供应链专家Tim,领导者角色的变化一定会影响到公司决策。但我相信这不会太坏,乔布斯的精神和气质通过他的产品,文档,技术影响着用户和开发者,对于苹果员工想必更是如此。特别是苹果那些和他一起工作了15年20年以上的核心员工,他们一定能将这些宝贵财富贯彻始终,并使之继续流传。苹果和乔布斯仍然有很多人们不知道的事情,那些想法和决策的产生,如何说服合作伙伴…这些恐怕只有在10月24日发布的乔布斯官方传记中才能得到答案了。

在苹果的世界中,创新远未到终点,苹果在之前很多年投资了很多技术公司,包括这次我们见到的siri,还有传说到未见产品的液体金属 Liquidmetal Technologies ,终有一天,这些技术会足够成熟可用,变成产品到达我们面前,那一刻,我们的生活会再次随之改变,如同苹果宣传资料上最喜欢写的那句”再一次,改变世界”。苹果的疆域扩展也未到终点,我们能看到的领域还有一贯有积累的教育市场,完成了准备工作的企业市场,还有面对客厅的Apple TV。未来还很广阔也足够令人激动,做为开发者或者创业者,我们对乔布斯最好的纪念是记住Be youself,做你喜欢的事,做和其他人不一样的事,改变这个不完美的世界。

 

 

 

PHP代码中,经常用到比较复杂的需要单引号和双引号一起运用的情况,对此,一直不是很理解,经过实际测试,似乎加深了理解。

代码如下:

<?php

echo "SET NAMES "."<br />";
echo "SET NAMES "."utf-8"."<br />";
echo "SET NAMES "."'"."utf-8"."'"."<br />";  //输出结果是: SET NAMES 'utf-8';
$db_config = array
(
		'hostname'=> 'localhost',
		'username'=>'root',
		'database'=>'week',
		'password'=>'',
		'charset'=>'utf-8',
);
$a = "<br />";
echo $db_config['charset'].$a;  //  输出结果:utf-8;
echo "SET NAMES "."'".$db_config['charset']."'"."<br />";  // 输出结果:SET NAMES 'utf-8';
echo "SET NAMES ' ".$db_config["charset"]." ' "."<br />";  // 输出结果:SET NAMES 'utf-8';这行代码比上一行简单一点,虽然理解起来要稍微难一点。
echo   "\""."SET NAMES '".$db_config['charset']."'".'"';  //输出结果:"SET NAMES 'utf-8' "; \",对双引号进行转义, '"',是两个单引号之间夹一个双引号,从而输出一个双引号
?>

输出结果如下图所示:

© 2012 QQ茶社 Suffusion theme by Sayontan Sinha