MySQL修改字段名称

今天需要修改一下table的某个字段名称,以前PHPmyAdmin用的比较多,较少接触alter命令,就直接查了一下,找到了这个命令:

alter table {table_name} change {old_field_name} {new_field_name} {filed_value_type};

误以为field_value_type可以省略,输了几次都报错:
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1

真是黑人问号!不得已之下加上了field_value_type,居然执行成功了。顿时怒了,你特么不是在逗我么,我只是想改一下字段名称啊,为啥还得加上字段类型啊。

不过没办法,既然这么要求,只能这么用了。这边可以用describe {table_name}命令查看当前各字段的类型。

Clang需要注意的一些不同于其他语言的地方

1、C语言需要include对应的库的头文件,比如使用printf的时候就需要include stdio.h。库的头文件里面有函数的声明,这样编译器就可以判断函数调用的对不对了。
2、C语言里面没有字符串,只能使用字符数组来模拟字符串,如果模拟的话字符数组需要比里面所有字符还要多一位,因为最后需要添加一个“哨兵字符”。&switch检查不了任何数组,包括字符数组。
3、C语言中没有布尔值,只能用不为零的值和0两个值来模拟布尔值。
4、C语言中不会记录数组的长度,可以想象存储在内存中的数组是多么赤裸裸的样子。
5、C语言执行某个函数会有返回值,0的话代表执行成功,非0的话代表执行失败。然而在其他语言中,执行语句不会有返回值,只会当异常发生时抛出异常。
6、c语言中有指针,指针有点像对象引用。使用一个变量指针就相当于使用那个变量的复制品,不过复制品只能用*(pointer variable)的形式进行操作。
7、c语言中的数组在参数传递的时候不是copy值的,其实是退化成指针传递过去,但是函数中的参数声明不是声明一个指针啊,摔!
8、虽然《head first c》里面说sizeof(msg)结果是指针的长度,这边的msg是传递到函数中的字符数组!然而为啥在main函数里面长度好好的,这边长度就不对了,难不成main函数里面的msg不是指针?
突然想起来当年上C语言课时候老师貌似提到过,在main函数里面的msg变量会保存字符串长度,但是传递到函数之后就丢失了么?

Flux和Redux基本思路

Flux和Redux的基本思路都是单向数据流,但是说单项数据流太抽象了,还是说得简单易懂:
本来在Flux提出之前,大家在DOM里面直接写业务逻辑,方便快捷。
但是问题也有,比如Facebook的团队发现的诡异的小红点的问题。
那么如何解决,那就是DOM中进行操作之后触发一个请求,这个请求再被分发器dispatch到业务逻辑。

那么这样有什么好处呢?
这样系统中的所有可用的请求都做成清单,一目了然。
所有触发的请求都会经过一次Dispatcher,简洁明了。
只有Dispatcher才能接触业务逻辑,这也就是单向数据流这个词的来源。

一句话,DOM不能直接改Model了,需要触发一个请求,Dispatcher接受到请求再执行业务逻辑。

React的路由模块设计

如果从React的角度设计路由的话,其实还是比较简单的。
比如如果点击一个链接触发一个新的路由,那么你可以在这个链接写上这样的触发事件:

在Flux中添加Action:

updateURL(new_url) {
    Dispatcher.dispatch({ type: 'UPDATE_URL', url});
}

添加一个存储URL的Store

getInitialState() {
    return '/';
}

reduce(state, action) {
    switch(action.type) {
        case 'UPDATE_URL':
            return action.url;
    }
}

在Flux Container引入事件:

onUpdateUrl: TodoActions.updateURL,

在View视图中触发事件:

<a onClick={props.onUpdateUrl('/myURL')} />

在顶部Component之上添加路由Component:

function Router(props) {
    if(props.url == '/') {
        return (<App1 {...props} />);
    }
    if(props.url == '/myURL') {
        return (<App2 {...props} />);
    }
    return (<NotFound {...props} />);
}

当然,这样是最简单的方案,但是实际中肯定不会用触发点击事件的方式去实现更改URL,而是直接给<a>标签一个href,然后用户点击href,被事件系统拦截到了然后自动被分配一个Action,然后被dispatcher进行dispatch。

还有,用户直接复制url访问的问题,此时就需要系统在系统启动时检查一下当前的url是多少,然后在getInitial中获取当前url。

另外,还有一个古老的问题,就是把访问历史要记得添加到history里面去。

最后,还有一点疑问,就是用户手动修改url可以被拦截到么?是不是就可以避免重新加载。

粗浅了解了一下Velocity模板引擎的原理

今天阅读了一篇文章,关于Velocity模板引擎原理的,很有收获,所以简单的概括一下。

其实,一直在思考Velocity这种模板引擎和JSP的区别,今天才恍然大悟。
其实Velocity可以称得上是半个语言了,所有的Velocity模板都会被分解成语法抽象树(AST)。如果对语法抽象树没有概念的话,可以了解一下《自制编程语言》一书(其实我也没有看过这本书)。
但是如何将Java的Context和Velocity最后分解出的语法抽象树匹配起来,这个才是问题所在。

这边可以对照一下JSP,JSP作为纯正的Java,自然不用担心变量的匹配的问题,所有通过Request的Attributes转发到JSP的对象都可以恢复原来格式的对象来调用。
但是Velocity中分解出的语法抽象树却需要通过反射等功能来获取Java变量的值,替换语法抽象树中的节点。