Submitted by gouki on 2012, June 6, 10:35 PM
这是一篇2年前的文章,之所以会再拿出来说,主要还是因为其中的一些话仍然在打动我。虽然时隔两年,但这些内容并没有过期。
原文在:Flipboard:iPad 上的革命性社交新闻应用初探
部分摘要:
- 什么是 Flipboard?它做了一件非常简单的事情:把你的 Twitter 和 Facebook 变成了一本杂志。你还可以建立一个自定义的杂志,要么选用 Flipboard 内建的版面,要么直接导入Twitter 的列表。这是一个非常强大而且使用感受十分美妙的 Twitter 阅读方式。同样的,你也可以把个人 Twitter 帐号、或者某个品牌的 Twitter 帐号转换成 Flipboard。你可以在 Twitter上 跟随 Techcrunch,然后使用这个应用把 Techcrunch 转换为漂亮的像杂志一样的界面,这样的界面比任何其他阅读器都要容易阅读。
- 对于视觉的研究证明,如果一个页面有一行大标题,是其它标题的两倍,这个页面更可能被人们所阅读。图片也同样,如果你在一个页面上放的图片是同样尺寸,另 一个页面上放的图片中有一个图片比其它图片大两倍,人们会更加注意有大尺寸图片的那个页面。我们的大脑就是这样工作的,一个大的标题和图片在我们观看页面 的时候提供了一个进入点。
- Flipboard 是怎样做到这一切的?毕竟,我的账户在 Facebook 上有 1800 个好友,而在 Twitter 上,我跟随了 19,000 人,但 Flipboard 仍然成功过滤了绝大多数的“杂讯”(其他客户端没有这个功能)。事实上,它有自己的一套逻辑来选择关联性最大的内容。比如说:有大量评论的,很多人喜欢 的,很多人 retweet 的。它还会根据状态信息的内容来过滤相关的图片并把它们显示出来。(膘叔:不要相信这些话,如果这是真的,那人人都能做了。)
- 站在内容创造者的立场,我很担心这会将过多品牌效应和广告利益从他们身边抽离。比如,我分享 Techcrunch 的文章的话,得到的好处还要多于在他们的内容被分享到 Flipboard 中得到的。这 可不好。而且内容创造者也需要一个更好的方式来告知 Flipboard 他们在用的正文篇幅。现在 Flipboard 只是通过内容创造者的 RSS 种子来分析他们的同步规则,究竟是全文输出、部分输出还是仅输出标题,但是 Flipboard 需要和内容方就其自身意愿进行沟通,因为我相信很多内容创造方不会乐于见到目前他们在 Flipboard 中所呈现的内容。站在用户的角度,我发现这种阅读体验很棒,所以媒体还是应该和 Flipboard 多沟通、合作,而不是如默多克(Rupert Murdoch )一样激动失控。
-
位于加利佛尼亚 Palo Alto 的 Flipboard 公司创始人是 Mike McCue,Tellme 和 Evan Doll 的前 CEO,曾在苹果公司做过iPhone 高级工程师。
Flipboard 刚收购了 Ellerdale,这个公司开发了一组基于 Twitter 的实时搜索工具。Ellerdale 的联合创始人 和 CTO Arthur van Hoff 做为 CTO 加入了 Flipboard 公司。
van Hoff 说有两年历史的 Ellerdale 一开始的目的是开发一个个性化的网络产品,但是投资者认为风险大,所以它先开发了技术,然后找到了用武之地。只有到了现在,那个最初的主意才有了价值。 “我们一直在开发一个伟大的分析引擎,但我们没有找到将内容分类导出的传导机制,我们的站点只是一个演示,不是一个产品,现在加入 Flipboard 之后,我们有了一个伟大的产品“。
McCue 说 Flipboard 一开始会是一个免费应用,在未来,公司会探索广告,订阅模式,以及和出版商分享收入。公司也计划尽快加入其它的内容渠道,比如 Tumblr, LinkedIn 和 Yelp。
Flipboard 现在有 1050 万(10.5 million dollars)的投资,来自 Kleiner Perkins 和 Index Ventures。其它投资的风投包括 Twitter 的创始人 Jack Dorsey,Google 投资人 Ron Conway,Facebook 联合创始人 Dustin Moskovitz,Peter Chernin创立的 Chernin Group, Alfred Lin, Peter Currie, Quincy Smith, actor/entrepreneur Ashton Kutcher, 主流投资商 Kleiner Perkins Caufield & Byers, and Index Ventures。
--------以上这段是来自2010年的文章,其实也说明了几件事:
- flipboard 不是一个晚上造出来的,他基于了Ellerdale和Readability,这两家公司在事先都存活了多年,摸索了多年
- flipboard也是摸着石头过河,10年的时候,他们最多只有9个格子。而如今是2页的九宫格+列表
- 商店的变迁也是颇为巨大,从聚合到分散再到聚合。这其中经历了多少。。。
--------
准备转行做产品了。所以开始对一些内容进行慢慢研究。
Misc | 评论:0
| 阅读:15983
Submitted by gouki on 2012, June 5, 10:25 PM
不是说真的没用。但是真有可能,以前我的显示器就是22寸的,那时候外面都还是19寸,我用的很爽。屏幕大,用的爽。。。
当然我现在也希望有大屏幕的,但好象不太现实了。我当然希望有一台iMAC,一台17的mbp,两台一起用。但好象有点不太现实。光这两样东西,就要将近4W了。但真正算起来,这些其实也并没有多少钱。相对于一名开发人员的薪水来说。无非就是挤挤乳沟就有了。但为什么很多公司就是不愿意投入这些呢?不明白。真的不明白,好象越是把硬件搞的越便宜就越开心。
----以下是内容,来自:http://news.cnblogs.com/n/144016/
英文原文:Why Quit? Because They Have Bigger Monitors
好的技术人员向往具有很强的企业技术文化氛围的工作场所。但如何你能从外部看清一个企业的技术文化状态?这里要讲的是我使用的两个简单而好用的参考指标。
首先我要讲讲“企业技术文化”这个词指的是什么。它是指技术人员在一个企业内受重视的程度和重要性。它能从一些事情上体现出来:
- 公司里的决策是如何制定出来的?在一个具有很好的技术文化的公司里,技术人员参与要做什么、何时做、由谁来做等决策制定。并不是说有最终拍板权,而是有真正的发言权。
- 对开发软件这个工种是否尊重?开发软件是一种创造性的工作,这种工作需要有合适的时间和合适的地点。有些项目很难预测出究竟要多久才能开发出来,而公司能认可这种情况。
- 基础设施。当需要把精力放到非软件特征功能方面的事情上时,明白事理的人(技术人员,经理)需要花多少的口舌才能让老板知道这些工作的重要性?这通常是指一些运行时系统里的工作(比如扩充消息队列容量)或后勤服务工作(例如编译系统或版本控制工作)。
不幸的是,想通过一次交谈咨询就把这种底细都摸清是不现实的,除非你在这个公司内部有受信任、知道内情的线人。
他们的显示器有多大?
发生在我的前一个公司里的故事。我当时是技术经理,试图想挽留一个人才。团队里有个程序员辞职要去一个很小的但很新潮的公司。下面是我跟他离职前的谈话:
我: 为什么要走?
他: 因为他们的显示器很大。
我: (怀疑) 开什么玩笑?我们也可以给你配个大显示器。
他: 并不只是我——每个人都需要大显示器。
我: 这有那么重要吗?
他: 这反映了公司如何看待我的时间的价值。公司需要决定的是,多花一些钱买个大显示器让更多的像素映入我的视网膜是否值得。
现在我明白了,他说的一点没错。重视员工的公司会认为设备上的额外开销相比起提高员工的工作效率(和提升他们的幸福感)来说,后者更重要。让最好的程序员使用最好的开发工具来工作。大个儿的显示器是一个非常醒目的判断指标。
员工是否可以选择他们自己的邮件地址?
非技术人员很多时候并不认为邮件地址有多么的重要。可它是你网上的身份证。严格的邮件地址命名规范(姓的全拼加名的缩写,或更糟糕的名的缩写加 姓的全拼)反映出公司重视所谓一致性超过对员工的心情的关心。更糟糕的是,这种规定非常直白的让员工们感觉到自己被当成了“齿轮”或“人力资源”,而不是 一个了不起的个人。
(旁白: 让我们远离“人力资源”这个词儿。太难听了。)
这一点对我个人而言格外重要,因为我有一个很独特的名。如果你不允许我的邮件地址为sef@company.com
,那你在我的印象里会大打折扣。不仅如此,冗长的邮件地址名让人产生错觉,就好象是个邮件列表地址,但里面只有一个成员,可以忽略不计。它很重要,它是你 shell 环境的提示符;它很重要,它是whoami
命令的返回值。
最后一句话:我并不是在谴责你们这些不辞辛劳的搞 IT 的男孩和女孩们。你们让很重要的东西保持正常运转,但还不得不被迫遵守这些强加的规则。相反,我针对的是这些糟糕的制度(通常是根植于糟糕的企业文化 中),是它们使你们处于糟糕的境地。如果你身处这样的一个公司里,那跪下来吧,祈求阳光的降临。
Tags: 跳槽, 显示器
Misc | 评论:0
| 阅读:13009
Submitted by gouki on 2012, June 5, 9:23 PM
Yiiredis是Yii的一个插件。用来方便我们对redis进行操作。封装了一些常用的list,hash之类的操作,对于Cache也做了一个封装,但在方便之余,问题也还是不少。比如说,我们要对数据sort,取出平均值,取出最大值之类的。默认的方法就不能用了。虽然yiiredis的类用了Array的interface,但利用php的操作,总归不如redis自身的操作。
一些参考资料上就写的比较详细:
典型的比如那些在线游戏的排行榜,比如一个Facebook的游戏,根据得分你通常想要:
-列出前100名高分选手
-列出某用户当前的全球排名
这些操作对于Redis来说小菜一碟,即使你有几百万个用户,每分钟都会有几百万个新的得分。
模式是这样的,每次获得新得分时,我们用这样的代码
- ZADD leaderboard <score> <username>
你可能用userID来取代username,这取决于你是怎么设计的。
得到前100名高分用户很简单:ZREVRANGE leaderboard 0 99。
用户的全球排名也相似,只需要:ZRANK leaderboard <username>。
看上去也比较方便,不过我没有仔细看究竟是因为phpredis的实现有问题还是yiiredis的问题。等晚上睡不着的时候看看伦家的源码先
Tags: yiiredis
PHP | 评论:0
| 阅读:16331
Submitted by gouki on 2012, June 4, 6:05 PM
今天又遇到了这个问题,以前其实是知道的。IE下的cookie长度和firefox下不一样。GET的长度也不样。
但我在记忆中一直是当成4096来处理的。看来我脑子里想的更多的都是firefox或者chrome,今天遇到某些信息不能显示的时候,又想起这个问题。才发现:
原文:http://blog.csdn.net/tuwen/article/details/5257154
看见很多朋友讨论浏览器最大URL长度限制的问题。其实实际中URL长度限制是由2方面决定的。1 客户浏览器 2 接受服务请求的服务器端的设置。对于大多数用户来说,他们使用的浏览器是IE浏览器,IE的最大URL长度限制是2083字节,而实际可以使用的最大长度 为2048字节。
以下是微软方面的技术资料及翻译:
Maximum URL length is 2,083 characters in Internet Explorer
在IE中URL最大长度是2083字节
SUMMARY
摘要
Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters.
微软 Internet Explorer 限制最大统 一资源定位器 (URL) 长度为2083字节。
Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST
request and GET request URLs.
Internet Explorer 对最大请求路径长度也进行了限制,限制长度为2048字节。这个限制对 POST 请求和 GET 请求的URL均适用。
If you are using the GET method, you are limited to a maximum of 2,048 characters, minus the number of characters in the actual path.
如果您使用GET方法,您将受到最大2048字节的长度限制,减去实际路径中的字符数。
(注:实际可以使用的字符串长度=2048-请求页面路径字符长度)
However, the POST method is not limited by the size of the URL for submitting name/value pairs. These pairs are transferred in the header and not in the URL.
但是, POST 方法提交名称 / 值对不受 URL 长度的大小的限制。 因为这些名 / 值对是在请求中的header部分传输的,而不在URL中。
RFC 2616, "Hypertext Transfer Protocol -- HTTP/1.1," does not specify any requirement for URL length.
RFC 2616、 " 超文本传输协议 -- HTTP /1.1, " 未指定任何对 URL 长度要求。
由此文大家可以知道,实际在IE中可以使用的最大URL长度是2048字节减去您请求页面的路径长度。另外这个长度还受到服务端相应软件的限制。
--------------------
关于cookie,可以看一下:
Cookie常识
“同名Cookie”的分析
cookie,又见cookie
Tags: url, ie, firefox, chrome
Misc | 评论:0
| 阅读:19226
Submitted by gouki on 2012, June 4, 5:12 PM
这是一个流程图,来自于禅道,http://www.zentao.net/help-read-79236.html
可以在自己的项目中做借鉴啊
在禅道项目管理软件中,核心的角色有产品经理、项目经理、研发团队和测试团队四种角色。如果您现在的团队是采用敏捷开发的话,那么可以对应到 product owner, scrum master和team(dev and tester)。这几种角色之间紧紧围绕产品的需求展开协作,取得成果。禅道核心的管理流程全图如下所示:
其实以前公司有流程图,但这一张图相对会比较完善一点
Tags: 项目管理, 禅道
PHP | 评论:0
| 阅读:22689