WeChat API

The WeChat API

Last night I made a little bit of an effort to tinker with the WeChat API, for it seems there are many interesting things one can do with it. And since it is one of the biggest way of marketing oneself on earth. It turned out to be quite necessary that I know how to program with the WeChat API.

Two kinds of Accounts

There are two kinds of WeChat Public Accounts (At least that's how they call them), the Service Account and the Subscription Account. Service Accounts are for corporations, and other commercial entities, in-app menus and other features comes directly in the package with Service Accounts, and also, Service Account users can only broadcast messages once a month. Subscription Accounts, on the other hand, do not come with all the fancy features, including the in-app menus, perchases, and so on. However, if a user pays 300 RMB per year, the Subscription Account can also enjoy what the Service Accounts do. It all depends on to what extent a user want to do with this publicity after all.

Functions

All users will gain the WeChat API after they specify their addresses, what they do and upload a legit logo. Basic API functionalities are as follows:

  • Broadcasting Messages
  • Receiving Messages
  • Auto Reply

It seems to be quite simple, but in fact, there are a few types of messages:

  • Text Messages
  • GeoLocation Messages
  • Video Messages
  • Voice Messages
  • Graphic Messages

Now it is quite clear isn't it ? WeChat Account managers can utilize all kinds of informations on this platform, including user data, geographic informations to precisely market their products, interact with users programmatically.

Techonology

I tried to use some existing libraries:

But finally, I tried to do it on my own:

#encoding: utf-8
import os

import sae
import web

web.config.debug = True

from wxAPI import WeixinInterface

urls = (
    '/', 'Hello',
    '/weixin','WeixinInterface'
)

app_root = os.path.dirname(__file__)
templates_root = os.path.join(app_root, 'templates')
render = web.template.render(templates_root)

class Hello:
    def GET(self):
        return render.hello("你好")

app = web.application(urls, globals()).wsgifunc()

application = sae.create_wsgi_app(app)

Let's see what we can do here.

Tags vs Category

Universal Tagging vs Pre-Set Categories

There is a problem recent years on “Categorizing” items within applications, that is, whether to use Universal Tagging or Pre-Set Categories. Though I think the answer is quite clear, many, aren’t.

I still remember since the release of Gmail, google never used any “hard-coded” categories in it. Instead, they used tags. Yes, it’s very easy, basically you can tag everything, and you can create new tags. Items of different kind can be tagged, so that their relationship can be easily determined by a program. Also, from the angle of designing patterns, it is also recommended to use tags instead of categories. Why ? Because it iterates faster. With one set of code, program will be able to sort, filter, query, and order item lists within seconds. Moreover, tags, as objects can be created on the fly, which gave both users and programmers immense freedom on searching and managing objects.

The Interface

However, there is always a problem: how do we align the user interface with such convenient functionalities ? There wasn’t a problem on desktop applications, for there is always a screen that is big enough for users to choose with. On desktop applications, there is usually a “Tag List” for users to choose from. Still, take Gmail for example, the tag list resides on the left side of the screen, where user can manage very easily. Same thing can be seen on Twitter and Instagram, where tags become hash tags, enabling users to search posts much more efficiently.

So there is no reason to use categories any more, right ?

Sadly the answer is NO and it’s quite solid. Look at the interface of WordPress itself, actually categories and tags Co-Exists. Confusing, isn’t it ? But there is quite a good reason for that: users need to put their blog posts into “big” categories, tags are only for searching. Though, tags can also be used to categories, however, any blogs with a certain tag will be included into a category page, which is not what the user wants. Instead, the user wants something like a drawer in their “Mind Palace”, so that they can put things inside.

And thus, came the ultimate problem. The Wardrobe, it is quite clear that the wardrobe need both categories and tags, with a limitation on mobile screen sizes.

Though, we believe in the near future human beings will eventually abandon the use of small screens. We have to implement both Category and Tags upon creating our wardrobe items.

How to squeeze the complicated interface into the tiny screen, remains a problem.

大师的烦恼 (一)

日本有偈语:「孤独に歩み、悪をなさず。求める所は少なく、林の中の象のように」。译成中文就是“独步天下,吾心自洁,无欲无求,如林中之象。” 毫无羁绊,清心寡欲的独步于世间,冷眼旁观着芸芸众生蝼蚁般的生活,一向是让一位大师在这滚滚红尘,金伦事务中保持心如止水,保持专注的人生态度。佛经说得好,万恶都从欲望中来,在这“他人即地狱”的世界里,很少有满足自己的欲求而不伤及他人的“善事”,那么少欲而寡求者即是大善。历年来,这是大师贯彻始终的“人生政策”。然而,人终究要在本我于超我的斗争中让本我获得胜利。没错!再多的道理,始终是敌不过脑中分泌出的那微不足道的多巴胺的。它,就如同一种迷药,让多年埋首于无我境界中的大师,无法自拔,深陷其中,痛苦不堪。

大师曾经采取多种方法来对付这个恶魔。

首先他试图遗忘。是的,正是在三年多前的北京,一个寒冷的宗教集会上,大师第一次遇见了这个棘手的对头。短暂的交锋之后,大师回到自己的庙里,心里默念着:忘却即是救赎。虽说大师很快就忘记了这位对手,这位对手的消息经常在寺院、教会中传播。在教会的定期刊物里,也经常出现这位对手的消息。“若这位对家找上门,九死一生。” 大师心里默念着。

つづく

PAAS Comparison (2014)

Abstract (概述)

2006年8月,亚马逊的EC2 (Elastic Cloud) Aplha上线了。从那时候开始一直到现在(2014年1月),已经度过了将近八年时间。八年,对于高速发展的互联网和IT业来说是一段很长的时间,从2006年开始的8年中,发生了许许多多的事情:智能手机,平板的诞生。Android,iOS的迅猛发展。3G - 4G网络技术等的发展,等等。PaaS,( Platform as a Service - 软件作为服务的贩卖形式 ),也经历了八年的发展,不过潮起潮落,在同一个竞技场里的玩家在这八年当中却只有区区6家,超过5年的老玩家只有3家。这足以说明要运营、支撑一个面向全世界的SaaS服务并不容易。更值得一提的是,看成全球最大电商的阿里巴巴在2012年停止了其PaaS业务。PaaS的运营和管理有多困难,其系统有多复杂,可想而知。那么当前,如果想将自己的WebApp( 网络应用 )部署在PaaS上,作为开发者和公司有些什么选择呢?在这些平台之间又应该如何选择,如何进行比较,同时又存在一些什么价值陷阱?在未来的几年之中,这些PaaS又将在什么的驱动之下向何处发展?笔者,都将在接下去得文中详细陈述。

Main Players (主要玩家)

当前,在PaaS的供应商中,有以下四家家主要玩家: Google App Engine, Heroku, Sina Application Engine, Parse.com

Heroku

Heroku作为云计算平台,于2007年诞生,其搭建在Amazon 的EC2上,故经常被人误认为是Amazon提供的PaaS服务。在其诞生初期,只支持PHP和Ruby。并且随着时间的增加,更多语言和解决方案登陆Heroku,使Heroku成为当前最成熟的PaaS之一。

Google Application Engine (GAE)

事实上云概念的真正普及者是Google Application Engine,在2008年之前,无论是Heroku还是EC2,都是在技术圈少数人在研究的东西,很少有一般人去涉足云计算开发的领域。一直到2008年,Google推出了Google Application Engine,让许多独立开发者和公司第一次接触到了云。同时,因为在Google Application Engine有大量的免费用量(Free Quota),使得很多个人开发者蜂拥而至,在GAE上搭建博客,论坛等等。在创建初期,GAE只支持Python和Java两种语言。

新浪云计算平台 (Sina Application Engine)

始于2009年,新浪云计算跟进国外的脚步的速度还是很快的。在内测的时候就有PHP一种语言,之后又添加了Python和Java。新浪云计算的收费和Google Application Engine相似,收费标准在初期比GAE低很多,吸引了很多国内的开发者驻扎新浪云计算。到后期,还有一部分的大学,机构将主页托管于新浪云计算。从目前看来,国内运营的最好的PaaS是新浪云计算。

Parse (Facebook的Parse.com)

始于2012年三月,Parse.com是一种新的PaaS,虽说Parse.com和GAE,Heroku提供的服务很相似,但是他们却自称BaaS (Backend as a Service),翻译成中文就是:

后端( 设备,程序,管理 )作为一种服务

笔者认为BaaS也可以归类在PaaS中,因为像Parse.com也是一个平台。本文的后面几个章节中,笔者还将说明BaaS和其他的PaaS有什么样的区别,以及利弊。

其他玩家

阿里云 : 阿里巴巴也有一个云计算平台,不过目前只有SaaS服务,即出售类似于VPS的虚拟机,其价格也和其他的虚拟机服务商没什么区别。阿里巴巴还有一个叫做ACE的PaaS,只是内测已经持续了两年,只有手持激活码的人才有机会体验。同时,阿里云还有租期一到立刻删除资料的情况,屡屡遭到业内朋友的讥讽。

cnode : 曾经红极一时的NodeJS云计算平台,不过因为资金不足,在Node 0.8的时代就夭折了。

百度云 : 百度也有一个PaaS平台:BAE,目前支持PHP,Java,Python和Node.JS几种语言。它的最终API的调用方式和SAE十分相似,界面也有雷同之处。这个服务,在2013年12月16日开始处于免费测试阶段,未来前景不明。

kinvy.com : 2012年2月推出的平台,主要面向移动应用的BaaS。意图在缩短制作移动应用的时间和成本。值得注意的是,Google Application Engine为kinvy提供运算资源。

比较标准

在开始比较这些平台之前,最重要的必然是确定衡量这些平台好坏的标准了,笔者希望通过以下分类来对当前的云计算服务平台来进行分类和打分。

用户体验

作为平台提供商,给予使用平台的用户提供一个简单而有效的用户体验是非常重要的,在选择平台的过程中,笔者认为用户体验包含:收费方式,用户界面,用户文档,免费额度,部署方式以及开发环境。通常,开发者会根据以上几个因素的价值衡量,来选择适合他们的云计算平台。这几个标准当中的任何一个的条件太坏都会导致用户向其他平台的迁移,在最坏的条件下,用户甚至会选择向VPS转移。在这些条件之中,收费模式和免费额度为变量,用户会可能会根据其它平台的收费性进行函数式的选择。

  • 用户界面 : 用户界通常被认为是一个次要因素,虽然平台体验对于用户来说是连续而整体的,但是界面的是否好用,是否对于友好,在其它的评判标准一致的情况下并不会被列入关键判断标准。举例来说,虽然Heroku的用户界面是HTML5,并且是响应式自适应的,其配色以及设计都让人感觉是经过精心设计的。Heroku的插件页面非常详细的罗列了插件的价格以及种类,同时收费标准也一目了然。用户在与Heroku的界面发生交互的时候,会自然产生对Heroku的粘性,并且更愿意留在Heroku。然而对于中国用户来说,因为线路问题,访问Heroku非常的缓慢,尽管Heroku的界面如此友好,但是不少用户,(主要是使用Python和PHP的用户)应该会舍弃界面的因素而考虑使用新浪云计算。当然,新浪云计算的用户界面和Heroku的对比起来,就缺乏设计感,显得苍白而古板。其MySQL数据库的管理界面居然直接使用PhpMyAdmin,虽然使用起来相当的熟悉,但是却让人颇为哭笑不得。除此之外,新浪提供的PhpMyAdmin还经常跳转到其它页面并且出错。如果不是因为网络速度这个特定的因素,也许很多用户会直接放弃使用新浪云计算。在国外的一些技术博客中,也有一些开发者声称自己因为Google Appliation Engine的界面太难看而转投Heroku。

  • 用户文档 : 文档,对于开发者来说很重要。因为如果没有一个平台的详细API(Application Programming Interface)文档,那么开发者在其平台上的开发就回如同盲人摸象,通常会造成设计模式上的错误。并且这样的错误在发现的时候,基本上都会需要重构。因此,云计算平台的文档是否健全,是一个相当重要的评估因素。在上述的主要平台中,每一个平台都会定期更新开发文档,例如新浪云计算的开发文档就托管在Github上面。用户可以在Github的源界面中看到这个文档的更新履历。这样,文档的可信度就增加,用户一目了然。对比Google Application Engine和Heroku的文档,都只能说是中规中矩。毕竟,如果没有一个完整的文档,开发者在这样的云计算平台上将寸步难行。同时,值得注意的是,开发文档也能很好地体现当前这个平台真实情况,例如:在新浪云计算的Python文档中有这样一句话:

    Warning:本feature还在开发中,目前还很buggy。

    这句话,让笔者感到很恐慌:因为我们都知道目前新浪云计算还处于Beta测试阶段,的确会出现一些bug。但是"很buggy"这个形容词,却不能让用户知道 1. Bug究竟在哪儿。 2. 这个Bug有多严重。 3. 什么时候这个Bug会被修复。 看到这句话的多数开发者应该不会去使用目前的syncdb功能去同步本地的开发数据到线上的数据库。这句话,让这个功能变得毫无意义。笔者认为,这对于一个PaaS来说是有点不负责任的。相比之下,Heroku和Google Application Engine的文档中就没有出现过类似的注解。在类似Parse.com和Kinvy.com这样的新兴平台中,就更不会出现这样的注解了。

  • 部署方式 : 部署(Deploying)是一个很重要的环节,如何从开发环境(Development Environment)向生产环境(Production Envrionment)部署,这个过程与工程本身的版本控制有着很大的关联,如果部署过程的版本控制系统和开发者使用的版本控制系统有着比较大得差异,或者造成直接冲突,这对整个用户体验来说是一个重大的影响,成为用户向其他平台迁移的动力。比如说:Heroku的部署和版本控制是使用Git的,它的部署方式很简单:只需要在开发完成之后向本地代码库(Repo)中添加heroku的remote,然后git push heroku master,就能达到向生产环境部署的效果。同时,如果开发者想要在bitbucket.org或者github.com同样也保存代码,就会变得非常简单,他们只需要向本地开发的代码库添加不同的remote就可以达到目的,并且在推送的时候制定推送目标即可。同样的git系统并不会导致冲突,这也是为什么Heroku项目在Github.com能够始终保持旺盛人气的原因。Google Application采用一个独有的部署系统,但是它不影响其他的版本控制系统,Google Application Engine的命令行工具可以与任何其他版本控制系统共存。这样的部署系统比较可靠,同时具有跨操作系统的特性,比如Google Application Engine的appcfg.py就是一个能够在各种平台上进行部署的解决方案,在任何平台上只需要一个appcfg.py --oauth2 -A <your-app-or-project-id> update <project-directory>命令,就可以部署到Google Application Engine了。而新浪云计算和Heroku都需要安装git以及其他的依赖包,而对一些新手开发者而言,在windows上部署cygwin之类的程序的学习曲线太陡峭,令人望而却步。最后说一下新浪云计算的SVN部署系统。这个系统算是中规中矩,如果开发团队还在使用svn版本控制的话,也许没什么大问题。如果开发团队使用的是git的话,那就会有点麻烦。笔者不止一次听人抱怨要把每个文件夹下的.svn文件夹加入到.gitignore文件里面去,最后导致一些用户放弃使用新浪云计算。在这点上,百度云计算(BAE)就要支持svn,git,在线编辑和包上传更新四种方式。笔者认为,在这样的情况下,会造成更多的用户转向BAE。

  • 开发环境 : 一个PaaS为用户准备的本地开发环境也很重要。

    • Google Application Engine:

      从08年到现在,Google Application Engine都是使用appcfg.py来在本地虚拟在平台上的环境的,因为Google独有的GQL(Google Query Language)的原因,appcfg.py中虚拟了一个本地的KVDB,让用户的代码在线上和本地运行时有相同的效果。这种开发环境的好处在于它能够在任何平台上使用。Google在发布appcfg.py的同时,发布了一套桌面应用。虽然在09年之前只有Mac用户才有类似的界面,在09年之后Windows用户也同样可以通过点击图形界面上的按钮来操作应用的发布,删除,部署等等。

    • Heroku

      总的来说,Heroku并不鼓励用户在Windows上进行开发。在互联网上铺天盖地的教程当中,很少有详细描述如何在windows下开发heroku的webApp,也很少在StackOverFlow.com看到类似的问题被解答。这是因为,尽管Heroku提供了它的ToolBelt, 开发者还是需要将其放置在一个类似于cygwin的虚拟环境中。而且即使这些虚拟环境都运行正常,在特定的语言环境下,有些依赖包会因为在windows下编译失败而无法运行。(当然,笔者认为在windows下面做PaaS上的web开发本身就是一件比较复杂的事情,因为必然会有一些依赖库在windows下编译失败。) 在*inx(unix, osx 或者linux发行版)下,heroku的开发环境表现完美。在安装完Toolbelt之后,基本上不用什么配置,就可以直接在本地进行开发和测试了。

    • 新浪云计算

      新浪云计算一直都在模仿Google Application Engine,不过它的本地开发环境又变得有点像Heroku -- 必须手动设置环境变量。在Google Application Engine的应用配置文件中,不会需要书写类似于下面的语句:

      if env == "development": '....' elif env == "production": '....'

      不过在新浪云计算的配置文件中,却需要。这会让一些很有"洁癖"的开发者感到不满。同时,以后万一要把代码移植到别的地方去,修改这些配置文件也是相当头疼的事情。新浪云计算还会发生,本地测试通过,而部署之后不能运行的状况。当发生这样的情况的时候,如果不能在互联网上搜索到答案,那么唯一的方法只有找新浪云计算的客服了。

    笔者认为,在2014年当下,国外的PaaS的开发,部署工作流程都做的不错,而国内的都做的不够好。开发者有时候会为了部署上的一个小bug而折腾好几天,造成效率的巨大降低。

  • 免费额度 : 每一个开发者都希望PaaS供应商能够提供更多的免费额度来支持自己的开发,这里笔者将对比不同平台提供的免费额度。

    • Google Application Engine:

      Google Application Engine的费率显示在这个页面上。在初始状态下,用户拥有5GB的Blob存储空间,1GB静态页面和代码空间,1GB数据空间以及每天50,000次的读写次数。在免费的Quota中建立一个自己的博客,或者是静态站点,绰绰有余。

    • Heroku:

      Heroku提供的免费硬盘空间和存储空间与Google Application Engine相同。但是免费运行的Dyno数量和GAE的Instance略不相同,可以说Heroku更加小气一些,如果笔者在Heroku建立一个博客,并且这个博客变得小有人气(每天有超过100人访问),那么笔者很可能需要为这个博客开始付钱。

    • 新浪云计算

      新浪云计算没有免费额度,他们只赠送开发者一些"云豆",用来抵用开发者使用新浪云计算开发时使用的资源。在没有进行开发者认证和身份认证之前,用户需要为流向自己应用的所有流量、存储空间以及运算时付钱。

    • 百度云计算

      百度的PaaS,将于2014年2月1日开始收费,其最贵的E套餐,折算下来一个月39元。提供1G内存和2G磁盘空间,不过这种雷同于SaaS的收费计量方式让人觉得很费解。

    • Parse.com

      Parse.com的免费额度大的惊人,包括每个月100万次请求,和100次消息推送。这要比前面任何一种都要多得多,不过,因为BaaS不需要托管静态页面,它的成本要低得多。

    • Kinvy.com

      Kinvy.com并没有标明免费额度中的API请求次数,不过同样作为BaaS,它提供的免费推送次数达到500次。笔者试图计算500次推送在GAE或者其他的传统PaaS平台上将换算成多少Instance Hour.

Github Blog Teaching

チャレンジ

素人にプログラミングを教える事が難しい。なぜなら、プログラミング自体が難しだけではなく、先生が生徒の事がどれくらいわかるのも関わってくる。さらに、その生徒が女である場合はもっと難しくなる。「マグルが魔法使いに変わる」と言う喩えが正しくなってくると思います。

分類

技術に対して、多くの人々は無関心と無知な態度を持っている。なぜなら、技術はミステリーであり、理解しにくいからだ。技術というのは常に完璧な状態で動いているだが、時々理由なく動けなくなる。無知から恐怖を生じる、が技術に恐怖を持つ人間が居るが、それに好奇心を持ち、研究している人も居る。今の生徒は好奇心を持つ人間だ。

教える事

生徒はかなり熱狂ですから、私はすぐ彼女にテキスト編集ソフトやデバグコンソールを見せました。それから、HTMLのタグの付け方や関係などを教えました。意外な事で、彼女が早くHTMLの作り方を覚え、数時間で何ページでも作った。いい結果でしたが、練習と深い理解が足りなければ、即ち間違いの理解でものを作ってしまうだろう。なので、ロードマップとプランが必要だ。

ザ・リスト

彼女に勉強してもらいたい事は下記のものとなる:

技術

  • CSS
  • HTML Tags
  • Javascript / CoffeeScript

ツール

  • Text Editors ( Sublime )
  • Terminal
  • Linux Utitlities

最後の一言

今日はギット・ハブでブログの作り方を生徒に教えまして、生徒が毎日ブログを更新する事に望んだが、凄く驚かされたようです。彼女はいまのツール環境になれるのはもう少し時間がかかる事だ。なので、今は落ち着いてやるべきだと思う。これからの何週間一歩一歩進むべきだと期待している。

山雨欲来

下周就要去上海,北京了。异常的让人紧张,希望做到一切万无一失。

以上

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

CICC 首日

福冈机场

今天是CICC第一天,从福冈出发一直要飞香港,途中转机台湾桃园。

上帝保佑总是有些恶心的事情发生:

例如日本人居然觉得香港人会不给我落地签证,把我卡在办理机票的地方。卡了足足50分钟

我回香港都需要怀疑我是不是会有签证吗?!

据说如果,我[不是从日本飞香港然后回大陆]就不会有落地签证

换句话说,日本人觉得如果我从香港呆七天回日本,香港的出入境管理就不会给落地签!

然后他们还试图打电话去台北

台北机场

更加莫名,有两个人来询问我去香港之后的去向

于是我说,我到了香港怎么样完全是我自己决定的,去哪里都一样。

便没有人来再多烦了

难道是因为华航吗?

飞机上有点忐忑

香港边检

屁都没有发生!!!!!

我什么都没说就过关了!!!搞什么飞机啊,华航!!!!飞机烂就算了,还要这般刁难。

倒是越南人遭到质询近10分钟

到了香港,有种回到中国的感觉。四周的人都说中文,满街都是中文。

组里的三个女孩自然兴奋,我倒是一点也不,自从有上次误点的经历之后,香港的机场已经是熟门熟路了。

HKUST

科技大学果然不错,设施都很完善,稍后上图

今天去花旗总部参观,又要西装笔挺了。。。。。

就先这样。

上周小记

又是周一,下周这个时候我就应该在香港了。

经过一个礼拜真是感慨。相当不幸的是Team内部出现摩擦,主要是我和一个泰国女生。争夺控制,谁都不肯让。

也许我们坚持的都是对的,甚至有时候我们的观点是一致的。可是她就是不让我多说话,我一说就插进来让我闭嘴!

忍啊。。。。。我的天,而且她说话的口气像老板一样。让人很郁闷。特别在做PowerPoint上,也是相当的纠结。

说到底,做PowerPoint还是得我来。只有一个礼拜了。我们一定得把问题解决了。

三次模拟,第一次很烂,第二次终于好一点了,昨天那次还是不错的。

不过说实在,这都是建立在我们极度的忍耐中的,真是非常担心在香港会怎么样

而且现在除了比赛什么的,我们都不怎么说话,或者干脆无视。

这种人,的确是懒得和她多说。

好在我们的24小时的整个步骤都是经过仔细布局的。

所以,即使之间出现一些什么人际问题也可以很顺利的解决问题

不过我看我和Sarah同学之间的朋友缘分也大概算是结束了。

嘿嘿

ひさびさな更新

去香港考试结束,本来准备当天就回家的,傍晚约了某于还有某罗在又一城吃饭。越南菜。

碰头的时候老远就看到于了,黑色的上衣黑色的短裙。变成大美女了。。(感觉比去年的时候好看一点)

聊的相当的开心。

大概七点一刻左右出发去机场,八点45分才到。。。。最终结果。。。。。

我居然没有赶上飞机。。。。。。。。。。。。。

第一次错过飞机啊。。。。

因为记得某罗和我说过如果有问题的话找她,拨通了之后就说帮我解决问题,在香港教育学院过夜。

我的临时Room Mate是一个香港男生。有点腼腆。

冲凉之后趴床就睡了。。。。。2点的时候被朗朗的读书声惊醒。。。

"明天北京的张老师就要来了──── 在北京带咱们玩的张老师────── 他来香港参加研讨会,顺带旅游3天──────"

这是香港大学生的普通话课。。。。

睡不着,精神忽然变得很好。。。。

和此男生聊天到4点。。。。睡觉。。。。

--------------第二天-------------------

打算联系沙子婴。。。王旭维。。。

很失败的是某王没有联系上。。。。约了沙出来吃饭。

我和沙有6年没有见了。。。我的神。。。。

随后某罗也出来加入我们

边吃边聊。。。从午饭时间聊到晚饭时间。。。。

以前上课喜欢说废话的人聚会啊。。。

还有就是小时候喜欢殴打我的人的聚会啊。。。。。。。。。

沙变的很Cool,但其实是ツンデレ(没想到这么小时候就认识ツンデレ。沙,你变身团长吧!!!)[非ACG基宅腐人士不要把我拖出去埋了]

反正我是异常享受整个过程。(因为这句话我将不得安宁)

吸取之前一天的教训,我6点十五就出发了。。。。

在地铁站和沙远远的以一个简短的挥手别过之后,再回头瞬间就是九龙塘茫茫的人海。我脑中似乎浮现出临别的时候沙略带血丝的双眼,还有茫然的眼神....(读书太累了。。。)

8点15我到了机场!!!!!!!Yes !!! 在走过一系列的通道之后我到达了登机口。。。8点30

GUESS WHAT ! 我居然在9点45才上飞机,飞机10点左右起飞。。。。。(昨日なら乗れるじゃねか????!!!くそ香港人め!!!)

飞机起飞45分钟之内我们都在云层中。。。。。。。我可怜的心脏。。。。。。。。

最后我看到星星了才安定下来, BTW我旁边坐了一个香港老头子。。。。上飞机就托鞋子把二郎腿翘向我。。。我根本睡不着。。。

11点45分到达浦东机场

--------------------------------------------------------------------------

11月会再去香港。。。。这次不会重色轻友的。。。。更不用说是我兄弟了。。。。