Big O活动简介: 技术和产品人员聚集在一起,完成一个小型的互联网应用(开发时间在6小时内).整个过程24小时,第一周讨论产品方向,第二周做产品原型,第三周开发产品,第四周总结和展示.

第二周活动概要

@龚民 同学到场,为大家解答了关于微博开放平台的申请,支付接口和分成比例等问题. 我们小组要申请的接口已经搞定, 老谭(@谭晨辉)将在周日补齐产品原型.下周开始之前讨论的应用的开发. @焕岭@西米哥@陈镇波 同学组了一个新队,下周开始做产品设计. 何直群(腾龙),张翼鹏同学进行了围观并参与了讨论.

微博开放平台的状况

通过龚民同学的介绍和现场同学的提问,我们获知了微博平台的第一手信息.

申请地址

新浪微博开放平台已经开放了对外的申请,地址是open.t.sina.com.cn;认证密码: wiki / 14001400.

现在开发者可以直接申请,申请之后可以直接使用,但是推送到微博的数据不显示来源;申请通过审核后,显示来源.

应用开发注意事项

因为目前的互联网环境,微博平台不允许应用将新浪微博的内容进行二次传播.应用可以将相关内容展示到自己网站上,但是不能再发布到第三方.

不能满足此条件的应用会被关停.

应用API里边的搜索接口即使已经成为新浪微博开放平台的合作伙伴后还需要申请一次,申请标准主要考察上述注意事项.

新浪微博将添加应用页面

添加完成后,微博将拥有应用入口和应用管理页面,具体如下

• 个人设置页面添加应用列表和应用授权
• 个人微博页面右侧添加”我的应用”模块,可收起和隐藏.
• 微博广场添加应用广场页面,进行应用推荐

以上功能预计五月完成.

支付和分成

微博支付接口正在开发中,稍后将提供给大家.分成比例将力争2/8(开发者8);最少不会低于3/7.

运行平台支持

通过微博平台和SAE(新浪云计算平台)的合作关系,目前申请微博应用的同学可以拿到SAE的邀请码,享受SAE的免费配额.

超出SAE免费配额的应用在达到一定的活跃人数时,可向微博和SAE申请更多资源.另外SAE将在5~6月推出资源购买功能.

应用开发讨论

以下是部分讨论内容

• 微博上活跃的一批应用主要是 机器人和 用户关系类应用. 如微博指数,查天气 等.
• 基于好友和关系的一些小测试和文字pk游戏应该也有市场.
• 大量推送feed的应用会被用户和用户的好友unfollow,需要注意
• 和sns相比微博有特有的东西: 机器人式的交互;单向关注的信息流;名人和机构资源
• 关于社交游戏是否能在微博流行,还很难讲,大家可以尝试

Big O 小组进度汇报

微博关键字监控的项目已经申请了搜索接口权限,应该本周能通过. 老谭同学继续做产品原型(完成后会公布出来).

@焕岭@西米哥@陈镇波 同学组了一个新队,下周开始做产品设计.

Big O 流程存在的问题

从最近两周的活动,发现原来流程存在的一些问题.

• 要安排一个4~5周的连续时间并不容易.时间安排需要考量.
• 大家很难在一个较短的时间内讨论出一个有意思的产品,有部分设计和规划考虑放到线上和活动以外.
• 不同的人感兴趣的项目不同,每次聚会应该召集对相同项目感兴趣的人,这需要我们有一个线上的项目展示,其他人由此考虑是否参加.
• 大家对6个小时开发时间能作出来的东西没有概念,需要更多的典型应用来给大家整体印象.

我们将针对以上问题进行调整,如果你有好的想法和建议欢迎在评论中留言或者发邮件给 easychen@gmail.com .

PS: 之前选定的咖啡馆的顶楼非常不错,但是没想到木有wifi,我们只好又回到了3楼.比较挤…

下周地点未定,有建议的同学欢迎推荐.

No tags

by黑传说
开始时间：2010-03-23 原帖发表于“西西河”

ps：胡乱涂鸦的，目前还没理好思路，现在先占坑，以后有空慢慢修正（下面没有任何一段文字可以称为完善的，都需要进行或多或少的修正）。完工之时，此行文字去掉，欢迎有想法的和我合作一起完成，如果能像：why git is the best那样的排版效果，应该会更棒。因为本篇相信会和git与svn的对比类似
思路发起者：黑传说(jobinson99@gmail.com 恩，俺技术不行，所以只能提思路，而不能直接提可实现方案)
核心贡献者：
参与者（按参与时间排列，请按格式自己添加。格式：姓名/号＋联系方式）：
鸣谢：所有研究p2p的人，所有使用p2p网络的人

标题说明：这是一个非严格的标题，之所以非严格，是因为目前尚在设想中，而设想的起点就是：干吗需要域名？反对的是目前的域名体系，而不是域名本身。域名可能可以保留，也可能需要废除，完全根据的是实际目的需要，而这个目的就是：更可靠的、分布式互联网——或者说，是另一个互联网乌托邦体系。
也因此，很多名词需要重构，需要发明一些新词汇来准确表述。比如域名，可能就需要重新定义。

——————————————————————————–

缘起
最近在搞分布式计算的东西的时候，仔细看了bt的kad网络原理，然后今天又在星岛上看到一则新闻：
链接出处
下面是我综述
说goddady等国外域名注册商利用去年寒冬国内大力整肃互联网的时机，向国内站长们狂摇橄榄枝，于是国内有人认为此举违法，需要国内对这些国际域名商 进行制裁………………

看到这个，我吐血了，现在互联网创业的门槛已经够高了，这么穷追猛打，恐怕最终结果，会发展出另外的互联网模式来的，刚好昨晚深夜钻研bt的kad网络原理，就这么把这两件事给挂勾了，一个大胆的设想浮在我的脑海里：干吗需要域名？

目前的域名管理体系：
IP：在互联网上辨别一台电脑的方式是利用IP，但ip因为非语义化，不好记，需要引入符合人类语言的标识方式来指示（就是域名）。

根服务器：主要用来管理互联网的主目录，全世界只有13台。1个为主根服务器，放置在美国。其余12个均为辅根服务器，其中9个放置在美国，欧洲2个（位于英国和瑞典），亚洲1个（位于日本）。所有根服务器均由美国政府授权的互联网名称与数字地址分配机构ICANN统一管理，负责互联网协议(IP)地址的空间分配、协议标识符的指派、通用顶级域名(gTLD)以及国家和地区顶级域名(ccTLD)系统的管理、以及根服务器系统的管理。
目前中国有3个根域名“镜像”服务器。

任何域名解析都要经过这13台根服务器获得顶级索引，但并不是说访问 .com 会经过这些服务器，访问 .cn 就不经过这些服务器。
而每一个顶级域，不管是gTLD(通用顶级域)，还是ccTLD(国别顶级域)，它们都有自己的域名服务器(即该顶级域的NS记录)，比如：

　　 .com & .net 的域名服务器是：[a-m].gtld-servers.net 共13个
　　 .org 的域名服务器是：tld1.ultradns.net 等6个
　　 .biz 的域名服务器是：[a-h].gtld.biz 共8个
　　 .info 的域名服务器是：tld1.ultradns.net 等6个
　　 .cn 的域名服务器是：ns.cnc.ac.cn 等6个
　　 .jp 的域名服务器是：[a-f].dns.jp 共6个等等。
　　.COM .NET服务器全球也有13个，其中，美国有8个、英国、瑞典、荷兰、日本和香港各有1个。由美国Verisign公司管理。

此处留着贴图（全球互联网节点分布图／体系架构图）：

用户流程：
浏览器输入地址——》》到最近的域名解析服务器辨识该域名所对应的服务器IP——》》如果找到对应ip，则传送回ip给浏览器，由浏览器使用该ip，到达所需要浏览的网站。
域名解析服务器此时就是一个译码本的作用
性能考虑：访问都由一个256b的数据包完成（一个数据包13块）

特定网站流程：
注册唯一名字（域名）——》把域名绑定在特定ip上——》》在dns上写入域名和ip对应信息

（唵啊吽）问题的核心可能是ip地址资源？？？：域名只是ip的一个马甲，而ip地址分配采用的是集中式管理模式。
劫持ip和劫持域名服务器都可以达到同样效果。既然已经语义化了域名，为何不同时语义化了ip呢？把ip和域名同时统一？为了下面方便讨论，可先假定ip体系不变，而只是域名体系变更。

——————》》简单说域名是ip马甲好像不太准确，因为实际应用中，ip地址并非唯一对应域名，有时是一个ip对应多个域名，有时是一个域名对应众多ip。
ip和域名的区别实际应用中，可能更像是服务器物理地址和应用虚拟地址的区别。
因此，对于应用虚拟地址来说，并没有必要对服务器物理地址体系作颠覆。 应用是用户直接需要的，在新的域名体系下，可以clone到其他服务器里面，但仍然是同一个应用。

现有域名管理体系可能存在的问题
A、太过集中于某个大国阵营：坏处嘛，那就是美国的态度太重要了，不想玩了，就关了根服务器。看哪国不爽了，直接停止该国域名解析（伊战期间，伊拉克国别域名.iq就被停了）。美国太过强势，导致各国都试图建立自己独立的域名系统，把互联网割裂为局域网，不利于世界沟通。

B、太过依赖于十几个节点：假设个极端情况，所有的根域名服务器同时残废了，怎么办？才十几个哦，要同时残废难度还是比较小的。

可能存在的需求
A、大国要求控制互联网，都想控制的结果最终就是联合国安理会模式。（确实就有国家提议由联合国电信联盟（ITU）来管理，但被美国拒绝）
B、大国不想互联网喉咙控制于敌国之手，但网民也不想被国家过度控遏。
C、小国需要互联网的发言权
D、新创业的公司要求打破现有的域名体系，降低成本（好域名都被占光了，却没好好用，创业公司要搞个好域名，需要的成本太高）
E、大公司也备受域名占用困扰：域名的多样性，容易被人钻空子，比如谷姐，北度，八度（不过，他们财大气粗，根本没需要我给他们代言）
F、现有域名体系无法有效保护网民：某个域名是否可信任，无法判断，有必要引入信任机制。
G、现有域名体系，只要有域名，就可以制造无穷多的内容重复性网站，无法有效保护原创网站。所以有必要引入更专注于互联网内容，而不是基于内容关联性弱的域名体系。
H、众多基于互联网的新应用，要求互联网具备更高的可靠性：恩，没错，现有域名体系，导致这些和桌面紧密结合的应用不堪一击，留下了无穷隐患。

目标：
更可靠的互联网
何为更可靠：更不易受攻击，更不易被切断，更不易被欺骗
一个容易理解的标准：无论互联网那个关键节点断了，都不会妨碍其他人在互联网中的穿梭，只会妨碍到该被断节点的访问。
此处也涉及到速度问题，需要和可靠进行平衡。

思路
现在的域名相当于原来bt中的tracker，是为了方便网络访问的快捷方式，但这种方式和原来互联网的设计初衷就不是一致的。
互联网的设计初衷是提供一种生存能力特强的信息传输模式，要生存能力强，那么就要尽量避免只有一个中心，尽量分布式，鸡蛋放在多个篮子里。

而目前最好的实践，莫过于p2p网络下载，原来的bt下载中，bt-tracker还可以利用不同国家的政策，来躲避管理，类似于现在的域名商，利用不同国家的政策来规避不同国家的不同监管。但这种方式终究是有弊端的，谁也没法确保那一天该国不会像对待bt那样进行封杀，尤其是战争时期，这种封杀，不仅对普通的互联网企业，而且将对世界各国的国家安全构成巨大的潜在威胁。
这也是为什么中国一定要在国内也搞一套域名解析服务器的原因。

而如果参考bt的kad模式（为方便讨论，可以暂时把kad的那套全部引入，设想下效果），则根本可以不需要域名：只需要在相邻的节点互相保存对方的信息，那么整个互联网就可以构建起来

现有的域名机制将被推倒重来：
把每个网站都看成一个类似bt中的资源

相关联的因素
包括互联网的控制权，互联网的安全，互联网的易访问性，性能等

一些设想：
A、不再需要注册，不再需要根域名服务器（好像标题应该改为“不需根域名服务器的互联网”，因为实际上还是有域名的，只不过已经不是现在的域名形式了，叫 “站名”更合适）
B、名字可以重名（各种语言文字都可以作为名字，中文／英文／阿拉伯／俄……）：命名并非是像现在的简单命名，而是有附加另外的信息的，比如：sina＋ 新闻，sina＋游戏，可以是两个所有人。更甚的是：sina＋随机码
C、网站指向无关ip：现在很多大网站都不止一个ip的，而小网站很多是共享ip，于是，ip成了一个不痛不痒的鸡肋，除了表明硬件地理位置，几乎没啥别 作用。那么，以后就让ip直接去对应硬件地理位置吧，域名跟ip脱钩，自己可以本身就跨越了几个地理位置（kad中，为了保证节点在线率时时刻刻不是0， 复制了20份资源信息给该id周围的其他节点。此处也参考类似做法，所有网站的信息都自动备份若干份到其他机器上，不过这样可能行不通，毕竟机器是有所有 权人的。）
D、访问网站将类似于bt中的查找资源
E、域名／站名：站点可能是每个网站对应一个唯一的站点信息包————类似于bt 中的种子文件，但可以有短模式，不需要全部输入所有信息，只需要部分信息即可快速 访问——网友“老虎爱吃肉“说的没错，类似于现在google的那个i’am feeling lucky（其实这种域名访问模式有点类似当年的网络实名、中文实名之类的，只是机制不是集中控制式，而是分布式）。短模式就接近现在的域名形式了。
F、现有域名可以被兼容，但地址不再是硬写的地址，而是作为一个个可选标签，比如有cn标签的，则代表这是中国／中文的网站。

BT种子和新设计域名体系的一些对应关系
目的是为了方便理解，并体验下效果，实际不应该如此繁琐，用户使用上应该和现有方式一样：输入地址，访问之。
…………to be continued

网站唯一性／反伪造
A、引入社会化信任机制：借用搜索引擎的引用权重模式？（根据收藏夹统计结果？）
B、站点信任投票：缺乏投票的新站得不到广泛的引用（可以杜绝临时性的伪造站：长 期经营才有可能有信任度）？？？

性能／资源消耗
现在的域名体系，对域名解析的安排方法，和我这设想里的差别不大。
都不会完全复制，只会复制一小部分：
A、根据语言：这样就排除了绝大部分的了
B、加入类似于skype的supernode机制？

谁负责：浏览器

这种方式的好处很多：
A、网络生存能力/可靠性急剧提高
B、容易实施：不需要世界各国支持，只需要用户客户端改进，即可完成互联网的底层变革。同时，也兼容现有的域名体系（但现有域名体系只是一个可有可无的附庸）。

C、不再受制于任何一国政府：美国无法控制，中国也无法控制
D、允许域名重名（因为名字规则不再单单是名字，还有相应属性：可以在meta中规定），这样现在紧缺的这些域名，都将成为过去式。
E、人人都可以对应一个网站/站名/域名：很多人都非常讨厌自己的blog前面或者后面附上其他网站的地址，比如blog.sina.com.cn/xxxxx ，在新的域名体制下，将完全可以把xxxxx前面的部分去掉，而不影响使用（也无需注册，无需备案）。现有昂贵／廉价的域名，将飞入平常百姓家。
F、域名内容将紧密关联：现有域名和内容关联度不高，域名的指示作用有限，在实施了分布式域名体系之后，域名和内容将直接关联，将更加促进内容的发展。

对于浏览器的影响
A、浏览器输入地址的时候，需要更多的自动提示（类似firefox的智能地址栏， 甚至是opera的图形化标签栏的可见缩略图模式）
B、搜索地址即是搜索相关的资源（参照kad的双字典模式）
C、浏览器将类似于bt客户端，需要提供最初的几个起始点信息（现有浏览器里面默认附带的安全证书，已经在起到类似作用，但仍需扩充）

对于网站的影响
A、不再需要为想要的域名付出高昂费用，域名将不再需要注册。
B、需要更加注重社会评价，评价越低，将越被忽略
C、服务器本身也变成整个分布式域名体系的一部分，保存一份域名列表（类似现在的友情链接，但在此域名体系里面，将需要单独放置在根目录下）————当然，还有另外的方式，比如按机房来，而不是按网站来，这样可以有效降低小网站的负荷，将资源用于急需发展的部分。

假设一个实例？
………………to be continued
原文地址：http://docs.google.com/Doc?docid=0AeoCTmjcpOM5YWpqNjNrYzVqemNxXzgyZGdyNG56Zng&hl=en

我说：异想天开也是一种力量，虽然你可以很明显的指出这个构想里的很多问题。

No tags

Big O活动简介: 技术和产品人员聚集在一起,完成一个小型的互联网应用(开发时间在6小时内).整个过程24小时,第一周讨论产品方向,第二周做产品原型,第三周开发产品,第四周总结和展示.

上周Oplatform的同学在避风塘进行了亲切的会晤和友好的磋商,组成了史上第一个Big O活动小组.

由于我们彼此都很熟悉,于是跳过了第零周和第一周的内容,直接进入了第二周.

开发平台和开发环境

为了能在6个小时内完成产品,我们选择的是Mash Up类的小应用,基于新浪微博开放平台和SAE开发环境.(由于我们在这部分拥有较多的资源和支持,前期我们都会覆盖在这边;如果有其他平台愿意提供技术辅导人员和运行环境,我们也强烈欢迎.)

产品方向讨论

新浪微博作为新兴的应用平台,我们很看好其在媒体和营销方面的作用.由老谭同学提议,在传播效果测量等方面做一些实验式的应用.Easy同学和青焱同学则进行了补充.我们想到的有价值的方向有如下几个:

• 传播效果测量,观察某些关键字在特定时间内的变化情况
• 查询机器人,如通过微博查询航班,这是一个很好的票务入口
• 聚合团购网站,通过微博来做团购,病毒传播效果更好

在充分讨论了各个应用的价值和优先级后,我们决定先开始做传播效果测量.

于是用思维导图完成了以下的基本思考:

每人分配了相应的任务后,本周活动就结束了.下周我们将讨论和制作产品的原型.

Big O计划正在进行中,如果你有兴趣参加或者参与组织,或者有任何建议,欢迎联系我们 easychen@gmail.com

No tags

Big O活动简介: 技术和产品人员聚集在一起,完成一个小型的互联网应用(开发时间在6小时内).整个过程24小时,第一周讨论产品方向,第二周做产品原型,第三周开发产品,第四周总结和展示.

上周经过我们的讨论,确定了Big O计划的基本草案.目前暂定以下流程.

在正式开始之前,Oplatform会自己建立一个小组,将流程走一遍.同时我们会邀请自己的朋友组成第二个小组,和我们一起开始.如果你有兴趣参加或者参与活动组织,欢迎发邮件给我们: easychen@gmail.com.

项目简介

大O计划,类似于国外的Open Weekend.利用周末的空闲时间,召集大家做一些实用的或者前瞻性的应用.
计划的目的是帮助大家了解web应用的开发流程,亲身体会新技术给互联网带来的新体验,为大家模拟一个相对真实的创业环境.

参与计划的流程

1 注册为大O计划参与人

用户注册为参与人,提供联系信息和注明希望参与的角色.

目前预定的角色有

• 产品设计(设计高保真的产品原型)
• 应用开发(将产品原型实现)
• 应用运营和观察员(在应用上线后,邀请好友试用,及时收集用户反馈并整理相关数据;同时负责记录整个过程)

2 项目发起和参与

每个人都可以发起一个项目.有以下必须遵守的规则:

• 项目全程开源,包括项目策划,讨论时的脑图,原型的源文件,程序的代码.Oplatform将在观察员的帮助下对此进行全程直播(通过博客和微博等).
• 项目发起人负责说服其他人员加入项目,并控制项目的进度.每个项目的预计开发时间必须在8个小时之内.最长用1个周末的时间完成.
• 项目产出将在BSD协议下发布,在保留作者信息的情况下,允许网友自由使用.如果项目开发团队觉得项目具有商业价值,可以自行在其上进行商业化,不用向Oplatform申请许可.

3 Oplatform提供的支持

• 组织和协调会员
• 和外部平台进行沟通,为参与大O计划的项目申请环境和技术支持.(第一期活动的平台和环境是微博开放平台和SAE)
• 产品设计,产品原型,平台技术,应用接口等相关技术的讲解和技术帮助

进行流程

第零周 – 人员预备

在网上预先召集一定数量的人员.按用户情况进行分组,每个小组4~5人.各类型角色不得小于一个.

第一周 – 应用开发讨论

介绍要开发开放平台和对应的接口,介绍提供的运行环境,介绍我们项目要遵守的规则.参与人员充分认识,并了解各自的技能.第一次聚会结束.留作业:每个人准备自己关于应用的想法.以备下次使用.

第二周 – 应用项目确定

每人提出自己的想法,在小组内充分讨论,整个小组决定公共项目.各小组决定完项目后,每个小组派一名代表轮流讲述小组项目.各小组项目互相评论.

(课后作业:产品类同学负责整理该类应用的定位,功能,同类产品信息;技术类同学整理相关技术,和可能使用到的技术资源)

第三周 – 应用项目原型(6小时)

前1~2小时是原型工具课程,由各小组的产品人员向其他成员讲解.产品人员不熟悉的地方,由Oplatform安排的同学进行解答.各小组分别完成自己的产品的原型设计,小组间互评.最终结果:产品定型,技术解决方案确定.

(课后作业:产品人员负责设计简单的界面,技术人员做相关的技术资源收集)

第四周 – 应用开发(6小时)

产品人员负责文案,流程,开发人员负责项目逻辑的开发;应用从最基本的功能做起,做完即上线,每一个小时追加一次新功能.产品人员负责邀请用户试用,并记录用户反馈.如果产品当天交流未开发完成,作为课后作业.

第五周 – 应用上线和运营(6小时)

应用正式上线,各小组介绍各自的应用,并分享一周以来的用户反馈和数据,总结经验教训.最新的文档和代码更新到Google code.本次循环结束.

最后再广告一遍 如果你有兴趣参加或者参与活动组织,欢迎发邮件给我们: easychen@gmail.com.

No tags