我竟然存了原贴....

没有项目 link....

#47 楼 @ruohanc @fsword 要不要来讲讲 erlang? 不过这个还是放在新纪元搞个一天的活动比较合适

这是一次成功的大会，团结的大会，与时俱进的大会

#6 楼 @sunfmin 内容不是字符串吗，只不过位置在变，你说的后台内容是啥

#4 楼 @sunfmin #3 楼 @huacnlee 这跟 websocket 有什么关系啊，就是基本的打印字符串。关键是每一轮打印的时候先输入 \x0c，也就是换页，所以每一轮打印都是一个页面，但是在原来位置，看上去就是动画了

ok. I'll be there if I'm available.

#11 楼 @xiaoronglv #13 楼 @zhuf #14 楼 @huacnlee 我还以为没人参加了，:)

#9 楼 @doitian 哈，先安抚一下老妈的情绪，:)

天冷了都没人出来动动了？

#2 楼 @lgn21st 刚发现这个残酷的事实。杭州的同学们，要不我们在末日来临前每晚来个 Ruby Night 吧

哈，做笔记很好，赞一个

#39 楼 @vkill 哈哈。虽然只有 4 位同学，但是我觉得今天的讨论非常好，没来的人可惜了。Go 真的不错，要用来做做真正的应用。感谢 @sunfmin 今天做科普，:)

#31 楼 @bhuztez 对这方面不了解，大概需要哪些背景，哪些资料可以参考？数据通讯走什么协议，有现成的吗？

#29 楼 @bhuztez 不是太理解。把本地的 Term 跟浏览器页面同步？

#29 楼 @woaigithub 发个邮件到 [email protected] 谈，:)

#2 楼 @sundevilyang 我今天发现杭州的 CodeRetreat 也在 12 月 8 号，难道是统一时间多会场活动的？@.@

#27 楼 @vkill 这个太让人感动了，得好好准备下...

@ichord @poshboytl 可能做过一轮修改，你可以找他聊聊，:)

#24 楼 @sunfmin 不知道是对活动不感兴趣，还是对 Go 不感兴趣，还是对应用不感兴趣，大家提意见啊

大家到这里报名吧：http://call4review.com/df83dd 我好买东西，:)

#18 楼 @sunfmin 有零食吃吗？没有的话我准备点，但是需要知道多少人来。

#10 楼 @sunfmin 领导，找你买鞋有优惠吗....

很好的项目，果断 fo

#2 楼 @bhuztez 不知道哎，等你来解决，可以周六过来

活动方式是：先由 @sunfmin 向大家普及 Go 语言的基础，然后下午大家组队（视人数分几个队伍）边学边干，有没有其他熟悉 Go 的人愿意来做 Mentor, :)

#38 楼 @bugreg 大而全的项目一般很少，除非是专门为大企业定制的软件，但是这种会非常复杂，用起来不一定符合你的要求，所以很多时候都要有所权衡，也是你认为目前没有找到特别合适的工具。Pragmatic.ly 本身是 issue tracking + task collaboration + agile methodology (支持 scrum)，discussion board 有考虑支持但是目前不是开发重心。但是，我有点怀疑对于 40 个人左右的团队做一个项目不是太适合，希望你能体验一下多给我们意见，谢谢

#13 楼 @xdite @fredwu laf. 是的话就搞笑了

#62 楼 @edokeh streaming 的连接理论上是无限长的，需要保持很多状态信息，而 long polling 相对只是保持一定时间的连接，很大程度可以依赖于请求带过来的信息。所以在开发上 streaming 需要处理更加的小心，包括心跳重连等，我说的难度是相对的，是说比起来。双向和单向两个没有区别，都是模拟的双向，也就是一开始建立连接后，只能从服务端给客户端发数据，而客户端要向服务端发数据，必须得另开一个连接。用 Streaming 还是 Long Polling 我觉得还是使用场景，在我看来更新非常频繁的比如 Twitter，是不大适合用 Long Polling 的，因为负载太大，而且延时严重

#59 楼 @edokeh 优势明显，劣势也明显。优势主要是针对在压力非常大的应用里，用 long polling 不断的重新建立连接是个很大的开销，但是大部分应用到不了那个程度，等于优势弱化。而劣势在于服务端开发更难，陷阱多，需要很小心的处理和管理连接。所以相比起来，long polling 目前被用得更多。可以等视频出来后看看我在这方面的一些想法。