Category Archives: 技术

我所经历过的一道微软面试题

一个老工程师,一言不合就让我写白板,让我在白板上手写一个简单的正则表达式匹配,只用匹配*和?号,惭愧,当时没写对啊。不过,我做面试官的时候,对于现在的小朋友,从来不敢出超过二分查找难度的题的,省的两个人都尴尬。

BOOL MatchString(LPCWSTR source, LPCWSTR expression)
{
    if(expression == NULL)
    {
        return (source == NULL);
    }
    if(*expression == L"")
    {
        return (*source == L"");
    }
    if(*expression == L"*")
    {
        int sourceLen = lstrlen(source);
        for(int i=0; i<=sourceLen; i++)
        {
            if(MatchString(source + i,expression + 1))
                return TRUE;
        }
        return FALSE;
    }
    else if(*expression == L"?")
    {
        for(int i=0; i<2; i++)
        {
            if(MatchString(source + i,expression + 1))
                return TRUE;
        }
        return FALSE;
    }
    else
    {
        if(*source == *expression)
        {
            return MatchString(++source,++expression);
        }
        else
        {
            return FALSE;
        }
    }
}

LLVM tutorial写的很棒

LLVM project的 tutorial 真心不错,从lex, parser, AST, JIT, optimization 甚至debug info generating都介绍到了,而且还用了最新的C++ 11/14标准,实在是编译器入门兼练习C++新标准的好资料啊,即使是门外汉,一个星期也能撸个自己设计的语言原型了,带JIT的哦!想起自己刚学习编译原理入门的时候,哪有这种好的资料,都是死啃龙书,LR1那一章不知道撸了多少遍啊……

面向对象设计的日常 (一)

无论是developer或者architect,先掌握好面向对象设计的技术吧,自从设计模式普及推广开来,面向对象设计似乎变得没那么难了,大家熟练运用,甚至死记硬背了Adapter,Singleton,Factory,Abstract Factory,Strategy,Command,Vistor几种模式后,code似乎都写的像模像样了,但最难的把真实世界(系统)抽象化的能力根本还是一团浆糊,大多数情况下是堆叠一堆设计模式去“套”业务,实在套不上的,来个全是静态方法的Util类,还不行?再来个含糊的全能Context类总行了吧,我自己感觉Spring的广泛使用对这种畸形设计起到了推波助澜的作用,多美好啊,再也不用认真思考对象之间的关系,对象之间的交互过程,千篇一律的无参构造函数,惨绝人寰的set/get方法冗长列表,需要的接口统统注入进来,还容易沾沾自喜,我这可是面向接口编程哦。
举个简单的例子,一个REST的api sdk,大多数api都需要一个http header包含了一个token,这个token可以通过post username和password调用另一个authentication service endpoint去获得,
一般的思路,对于接口AuthenticationService我们会有下面的考虑,这本身是非常正常的,因为对于一般的authentication service它的职责就是认证用户,但在这个case里,其实authentication service的职责是提供访问token,所以下面的这种就是一个生搬硬套,过于死板的设计,依赖于经验,我们很多人的第一个版本很可能都是下面这样,包括我自己。

class AuthenticationService {
    public AuthenticationService(String endPoint){
        this.endPoint = endPoint; 
    }

    public String getToken(username, password) {
        return fetchToken(this.endPoint,username,password, ....);
    }   
}

而下面这种设计则更好的体现了在这种上下文中的authentication service的职责,

class AuthenticationService {
    public AuthenticationService(String endPoint,String userName, String password){
        this.endPoint = endPoint;
        this.userName = userName;
        this.password = password;
    }

    public String getToken() {
        return fetchToken(this.endPoint,this.userName,this.password, ....);
    }
}

这两种版本的根本区别在于是不是认为username和password是AuthenticationService本身的一部分,在这个case里它显然应该是。

我自己总结的面向对象设计的三个基本准则,

  • 对象应该尽量是immutable的,所以当业务类有大量的set方法时,要慎重考虑设计,Spring框架注入需要的不在此列,

  • 接口是行为抽象的集合,可以这么想,我有一个实现了接口的类对象,现在已经完全构造好了,那么我有什么方法可以调用,

  • 你的设计出来以后,给别的developer使用友不友好,使用者是不是要大量的了解某种细节才能使用

最后一点非常容易自我检查设计是不是有坏味道。

一家之言,大家可以自己体会和发表见解。

Redux是如何工作的 (一)

凡是用reactjs开发的项目,但凡规模稍微大一些,都很可能要引入redux来管理组件状态的变迁和组件彼此之间的通信,权威的解释和说明当然是官方的这篇文章,但是,但是,但是,这篇长文处处透露着一种玄妙而不可言说的味道,处处是一些principle,best practice,never,absolutely,you should……的字眼,到处是强调,加粗的段落,一些模糊的store,action,reducer之类的抽象用词,我尝试着写篇小文来记录自己对Redux的学习理解过程。

1. 从reactjs本身谈起

正如官方文档强调的,我们只做view层,是的,reactjs利用JSX把UI的开发演进到另一种模式,就个人观点,我并不觉得其比其他基于模版的view技术究竟高到哪里去,有人说virtual dom技术比原来的直接操作dom来得效率高,拜托,它只是节省了dom元素的寻找时间,react使得程序员从数据变化耦合ui变化的面条代码中抽离出来,每个组件保持了极高的内聚性,给使用者带来了极大的方便,使得在view层堆积木式的开发成为可能,每个UI组件的state对于使用者是完全透明的,使用者只要为它设置好初始的props,组件本身可以响应各种事件来改变自身的状态,重新渲染外观。如果每一个组件都不需要跟外界通信,都不需要跟别的组件联动,那传统的state,props便足以对付所有的开发。但是组件之间的通信,这对一个稍微大型的SPA应用来说,都是必须要有的功能。

2. 我们能从传统的设计模式汲取什么

observer/observable,Event Listener是我们最常用的手段来注册,监听,响应外界感兴趣的变化,假设react组件A监听了组件B的变化,当组件B变化时它调用A注册的回调函数,同时把自己的state传递给B,注意,这里已经完全破坏了组件的边界,当A拿到B的state时,它可以做任何修改,所以实现时,B应该clone了一份自己最新的的state给A,那么问题来了,

1. A组件必须理解B组件的实现细节,不然它没办法理解B的state的含义,但state本身是应该对外界透明的。

2. 每个UI组件都必须暴露注册监听的接口

3. 大量的state复制操作

我们想一想如何自己解决这些问题,

1.  想不到,是的,真的想不到啊

2.  加个属性,不好办啊,A,C组件都想监听B的变化怎么办?

3.  前两个解决不了,这个就不是个问题啊

3. Redux 是怎么解决问题的

1.  计算机问题总是可以通过分层来解决,Redux引入了一个称之为store的层,所有的组件不再维护自身的状态,所有的状态都在这一层来维护,作为一个best practice,Redux推荐用扁平的方式来为维护这个store,所以每个状态都必须小心命名以防止同名冲突,一般的我都会加组件名作为前缀。

2.  既然组件不再维护状态的变化,那么组件的渲染必须通过组件属性的变化来完成,所以Redux在原组件外面重新包了一层,然后外层通过更新内层属性来触发内层UI的重新渲染,内层组件所有的数据通过props来绑定,同时调用通过属性传过来的回调函数来与外界通信,所以组件本身的内聚性得到了保证,组件总是通过属性来工作,需要特别指出的是,组件本身并不需要知道是否工作在Redux的上下文,它根本不知道action,reducer是什么东西,它只是根据传给它的属性来决定是否需要调用以及调用哪个作为属性传给它的回调函数,所以Redux本身也不需要必须和reactjs绑定,这个外部组件传进来的回调函数,它简单的dispatch一个action,action本身只是一个必须包含type属性的普通javascript对象,那这个action从哪里来呢?这里引入了一个action creator的概念,说白了就是一堆函数,每个函数返回一个action,他们一般都放在xx_actions.js ( xx代表组件名 ) 的文件里,这样看似多余的封装其实跟我们经常强调封装getXXX函数一样,它提供了一个hook点,使得我们有机会对action的创建有更多的额外控制,比如这个回调函数可以再返回一个function,这个返回的function调用生成一个Promise或者action,就像trunkMiddleware做的一样,第二个好处是同时避免了大量的创建不同action的逻辑耦合在一起。所谓的reducer就是action listener,它根据action的type来更新全局的store,很显然reducer针对同一个action会有多份实现,比如A,C组件对于B组件dispatch出来的同一个action有不同的反应。同时还应该有一个东西把各种必要的属性组合起来传递给我们的UI组件,具体怎么做,且听下回分解。

(未完待续)

React开发移动端h5应用踩过的坑们(持续更新中)

1. webpack 打包字体有时候会破坏字体格式导致浏览器decode失败,有的浏览器认为是警告,有的认为是错误,认为错误的直接不渲染页面

2. Object assign 方法不是全浏览器支持,尤其andriod和微信浏览器,需要自己找个polyfill

3. Promise不是全浏览器支持,尤其andriod和微信浏览器,需要自己找个polyfill

4. 这个跟react无关,主要是IE对flex布局的支持,对于flex:1 1 0,IE和微信浏览器直接扩展最后一个为0px,导致height为0,现象就是页面一片空白,写成flex:1 1 0%解决问题

5. 用ReactCSSTransitionGroup做页面间的滑动切换,只用定义appear的css,千万不要写enter和leave的,enter和leave是用来实现组件加入/离开组的动画效果。

6. 不要有工程洁癖,例如坚决不用jquery,坚决什么都用redux封装,有时候一个很简单的东西会被这种洁癖搞的很痛苦

7. 组件设计的力度不要太细,只对非常通用的组件做比较细力度的设计用来积累团队的code base,可以用于绝大多数项目,比如navbar,footerbar,infinitescroll list

8. 少用国产的React UI组件库,虽然看上去都不错,但是一用上,经常发现各种小坑

9. 认真读官方文档,有的虽然是短短一页,但是信息密度特别大,不仔细看经常会忽略某些非常重要的知识点

10. 一定要测试android browser,chrome for android,微信浏览器,不要只在自己的iphone上测了就OK了

11. 非常值得29欧买个jshybugger

12. Redux维护的state的生命周期是贯穿应用本身的生命周期,可能会积聚大量的数据在浏览器端,传统的组件自身维护state,组件销毁,state就销毁了,需要在不同的场景做取舍。

ReactJS应用的 UI layout控制

首先,在开发React之前,我认为应该是一件不太难的事,因为有比较丰富的backbone.js, marionette.js的开发经验,再加上大体了解它的思想,简单的认为和定义View的render,template的方法大同小异,只不过用了JSX奇怪的语法用javascript来代替html形式的模版。
刚开始开发的时候,一个页面一个页面的像玩具一样的写,觉得还行,然后开始重构,把一些公共的部分,header,footer开始往layout组件上分配,然后一下子懵圈了,这怎么搞?直觉上把组件按照层次放应该可以吧,parent组件怎么render children组件呢?果然发现了this.props.children属性可以用在parent组件里用{this.props.children}来渲染children组件,写到这得时候还算顺利,然后,问题来了,NavBar的title属性需要在每个children组件里设置,{this.props.children}怎么把属性传递过去呢?还是在官方发现了https://facebook.github.io/react/docs/clone-with-props.html,相当不认同他开头的那句,这不是最常用的场景嘛

In rare situations, you may want to create a copy of a React element

当然这时候我还没用Redux,Redux,Redux,重要的事情说三遍,所以我传了个setTitle的回调函数过去,在children组件的componentDidMount调用setTitle设置header的title,此时对React略有失望,尽管用javascript来代替html——相比较其他拼命加自定义属性来扩展html标签的语义——的思路是创新的,但也正是以组件为单位的思路导致了这种丑陋的,仅仅是为了从parent传递数据到children就得执行一个重量级的cloneElement操作,Redux的出现简直是挽救了React,如果没有Redux,React只是一个非常平凡的框架。回到项目,大致的路由设计如下,Home,Foo组件使用Layout,Bar组件有嵌套在Layout/Layout2中,

<Route  component={Layout}>
    <Route path="/"  component={Home} />
    <Route path="/foo" component={Foo} />
    <Route component={Layout2} >
        <Route path="/bar" component={Bar} />
    </Route>
</Route>

Layout组件的实现如下,

const Layout = React.createClass({
    ...
    ...
    setTitle: function(title){
        this.setState({title:title});
    }

render:function(){
    let childrenWithProps = React.Children.map(this.props.children, (child) => {
    return React.cloneElement(child, { setTitle: this.setTitle.bind(this) });
});
return (
    <div id="content">
        <NavBar title={this.state.title}/>
            {childrenWithProps}
        <FooterBar/>
    </div>
    )
    }
});

flask+flask-socketio使用方案总结

最近一个项目中碰到了这样一种非常常见的需求,一个网站有两种角色,一种是咨询师,一种是问问题的用户,一个直接的需求是,当有用户提问题的时候,所有的咨询师都能得到通知,当咨询师回答问题的时候,只有提这个问题的用户可以收到通知,用户可以对咨询师的回答进行评价,当评价完毕的时候只有回答问题的咨询师得到通知,这么一个简单的需求基本上涵盖了socket io的所有模式,三种实现方案总结如下,
1. 登录时为每一个用户和咨询师创建房间,例如’user_<user_id>’,然后分别在提出问题,回答问题,评价答案的环节,向对应的room来广播消息
2. 登录时根据角色分别加入’users’和’consultants’两个room,在不同环节向对应的room广播消息,然后由客户端来处理是否相应改消息
3. 混合方案1和2

项目是用flask+flask-socketio实现的,咨询师相关代码如下所示,要注意的是flask-socket有很多API是必须在socket io的上下文才能调用,

client端js代码,

var socket = io.connect(‘http://’ + document.domain + ‘:’ + location.port + ‘/consultants’);
socket.on(‘connect’, function(data) {
    socket.emit(‘join’,”);
    socket.on(‘question_added’,function(data){
    console.log(data);
    });
});

server端python代码,

@socketio.on(‘join’, namespace=’/consultants’)
def join_consultant_room(json):
    join_room(‘consultants’)

下面这句在user创建问题的controller里完成保存逻辑后触发,最重要的一点这个是配合room和namespace参数去调用,不必要在socket io的上下文中去调用,这个是我们有时候建立看似冗余的room的原因,
socketio.emit(‘question_added’, ‘question created’, room=’consultants’, namespace=’/consultants’)

用户相关的代码类似,不再列出。

Javascript检测用户按F5或者点刷新按钮刷新

对于SPA应用,检测用户是否按F5或者点击浏览器刷新按钮,因为一些重绘整体layout的逻辑需要在这地方完成,最近在项目中用下面的方法完成了这件事

window.onbeforeunload = function () {
    sessionStorage.setItem('refresh', true);
};

var isRefreshingPage = function () {
    var oldState = sessionStorage.getItem('refresh');
    sessionStorage.setItem('refresh', false);
    return oldState == 'true';
};