阅读笔记 20140218

Read Notes 2014-02-18

Python

virtualenv

A Python isolate virtual running environment

DouBan code review tool CODE

git repository and code review

Reactive

ReactiveCocoa - iOS开发的新框架

Design

Origami

A mobile app design tool by Facebook

Deployment

Docker: Using Linux Containers to Support Portable Application Deployment

AWS: Upload file to S3 directly

upload with progress

generate form signature, upload by jQuery file upload plugin

AWS S3: Browser-Based Uploads using POST Proposal

spec and demo

阅读笔记 20140103

Read Notes 2014-01-03

网站

技术人攻略

IT人的访谈 郑柯供稿中?

宁皓网 IT课程

主要以网站开发相关,几分钟一段,口音很奇怪的柔和。部分课程免费,是在线课程网站里见过做的最好的。

工具

bracks

开源的网页开发编辑器,实时反应变化,CSS自动补全等等,支持各种平台。

NOTE: 宁皓网课程中使用的编辑器

技术

Bootstrap

Twitter的前端开发框架,相应式网页开发必备。

NOTE: BootStrap常用模板 BootStrap相关的前端开发工具和库

html5-boilerplate

极好的HTML5 CSS页面模板,基础模板字字珠玑。可配合Bootstrap使用。

如何加入BootStrap

下载BootStrap,解压得dist目录,复制对应文件到相应目录,修改index.html,head部分css最开始的位置添加

<link rel="stylesheet" href="/css/bootstrap.css"> <link rel="stylesheet" href="/css/bootstrap-theme.min.css">

尾部添加

<script src="/js/vendor/bootstrap.min.js"></script>

函数响应式编程(Functional Reactive Programming:FRP)

一种和事件流有关的编程方式,一系列事件组成了事件流。FRP非常类似于GOF的观察者模式。被观察者是一种Monads(昨天刚刚看到有人在知乎吐槽Haskell里面的Monads)

  1. 事件流,离散事件序列
  2. 属性properties, 代表模型连续的值。

Reactive Extensions (Rx) 原来是由微软提出的一个综合了异步和基于事件驱动编程的库包,使用可观察序列和LINQ-style查询操作。Rx最显著的特性是使用可观察集合(Observable Collection)来达到集成异步(composing asynchronous)和基于事件(event-based)的编程的效果。 Rx的老家

The Reactive Manifesto 原址 中文

相关实现 Rx.NET: .Net RxJava: Java ReactiveCocoa: IOS RxJS: Javascript RxCpp: C/C++ Rx.rb: Ruby RxPy: Python 3

RxJava RxJava作为一个Functional reactive框架,提供了如下对被观察者的集合(事件流)处理能力:进行filtering, selecting, transforming, combining 和composing。提供Java、Scala、Clojure和Groovy语言实现。 netflix的介绍

RxJava on Android - http://www.jdon.com/45581 - http://www.importnew.com/8321.html - http://mttkay.github.io/blog/2013/08/25/functional-reactive-programming-on-android-with-rxjava/

分布式高并发 - Actor模型

AKKA: 基于scala的平台 http://www.jdon.com/45728 http://www.jdon.com/45516

42qu的源码

基于Tornado开发,很好的网站开发学习范例

hg clone https://bitbucket.org/zuroc/42qu/

Stackedit.io的源码

能否作为网站内置的编辑器?

杂类

Monad in Haskell

昨天看到有人在知乎吐槽Monad的理解,搜了一把,待学习

关于IoC、低耦合、配置文件及其本质意义的思考

看了一篇关于IoC的Blog《你真的了解Ioc与AOP吗?》,很是有点感想。

我之前对IoC了解一些但实际大规模应用的机会比较少,感觉它可以通过两种方式来改善耦合度关系:

1,通过“注入”实现功能替换。简单的“注入”,可以通过seter或者Constructor来实现。之后可以在运行期的装配阶段把各个注入类和宿主类组合起来。简单“注入”的缺点是,还是要将具体的注入类写死在装配方法中。

2,为了解决简单注入的问题,有人利用反射+配置文件实现了注入,现在只要修改配置文件就可以实现注入类的替换了。

所谓的“注入”,可以理解为一个回调的过程:把宿主类中要在运行期决议/替换的功能单独作为一个类来实现,然后把这个类的抽象(抽象类或者接口)作为宿主类的一个接口(通过seter或者constructor来赋值),最后在运行期把一个实现具体功能的实例赋给宿主类。上述的实现,宿主类要显式的标明注入类的接口类型,并且在装配阶段要显式的new出注入类,然后赋给宿主类的对应接口。这种事情,好处自然是有的了,就好像AbstractFactory或者Builder模式:只公开接口,把具体的实现抽离出来,这样可以方便的实现具体实现的替换。可是仔细看一下,这样的实现,耦合度从代码中转移到了装配类中。

而配置文件的方式,把类的装配工作以配置文件的形式实现了,这样不用修改代码、编译就可以实现注入类的替换。这样做的好处更是有的,不管怎么说,能够不修改代码实现功能的替换至少在发布方面是能够带来不错的效果。至于在代码方面能够带来多大程度上的好处,我想可能还是要视环境和应用的场合来定吧。毕竟这样做的复杂程度要比简单实现高很多了。而且这样的实现,事实上是把耦合从装配方法中转移到了配置文件中。

其实在IoC实现中花了很多的力气来做类型的匹配工作……宿主类和注入类的接口对应,这个是强类型语言所不能避免的。既然如此的话,那么无类型的动态语言实现IoC应该是非常的容易并且效果应该是不错的——可是同时负面效果就是运行期才能进行类型的识别和匹配工作容易出错,但目前似乎配置文件的方式也无法避免这个问题。

进一步的,配置文件其实也是可以演变、进化的。首先就是配置文件中的内容是否可以以元数据的形式出现?又或者以一个程序集的形式出现?该程序集其实就是配置文件或者元数据功能上的替代者——虽然修改不方便了,但是同时带来了安全上的保证。可是这样一来,我们又要面对编译的问题。呵呵,两难吧。

当下形形色色的配置文件已经泛滥成灾了,怪不得RoR要火爆起来。其实就配置文件来说,本质上是为了把耦合的位置从不可修改的编译代码中转移到一个可修改的文本文件中,这样就可以在替换部分功能的时候免除掉“编译”这个环节,为的就是这个效果吧(不知道这样说是否正确)。 虽然可以不用修改代码了但还是要修改配置文件,我个人感觉这本人本质上其实还是一回事。话说回来,如果这个趋势发展到极致,我想可能大家可以只用配置文件来写程序了,宿主程序则退化为一个配置文件的解释器——事实上,这个也是可以实现的,Eclipse和SharpDevelop的宿主程序已经是这样的一种东西了。XML的配置文件加一个解释器不就是一个新的语言么?如果不用XML做配置文件,而是用类似脚本的方式来定义配置,那么这个配置文件其实就是一个解释型的语言了。然后,为了提高这种配置方式程序的效率…… 我们兜了一个很大的圈子之后又转回到编译语言上来了。从这个角度上来说,这是一个平衡度的问题。 从更高一点的角度来看,这是一个螺旋式进化、演变、上升的过程。从现实的角度来看,未来二十年应该是解释语言和动态语言的天下。

退后一步来看这一切,我们当初为什么要OO,是为了降低大型软件中面向过程的封装问题导致的复杂性。有了OO之后,发现一切并不是那么的美好,为了降低对象之间的耦合度、增加灵活性,于是有了设计模式。人们应用了设计模式,发现调试不方便了,复杂性又提高了。IoC可以理解为是模式的一种吧,但是换一个角度来看,它不就是一个回调函数的OO方式的实现吗?我们果然是又转回了起点,下一步又要转向哪里呢?

这其实,都是为了解决软件的一种复杂性而导致的另外一种复杂性,所不同的就是人们可以选择自己更能够接收哪种复杂性。