<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0"  xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>大城小胖的大城</title>
    <description>我胖故我在 胖的没救了
</description>
    <link>http://fins.iteye.com</link>
    <language>zh-CN</language>
    <copyright>Copyright 2003-2014, ITeye.com</copyright>
    <docs>http://blogs.law.harvard.edu/tech/rss</docs>
    <generator>ITeye - 做最棒的软件开发交流社区</generator>
    <atom:link href="http://fins.iteye.com/rss" rel="self" type="application/rss+xml" />
              <item>
            <title>HTML5 与 ”性工能“障碍</title>
            <description>
              <![CDATA[
              <span style="font-size: large;"><br />HTML5 与 ”性工能“障碍<br /></span><br /><br /><span style="font-size: medium;"><br />最近看了@王淮Harry 的文章《HTML5的明天--局部有小雨》<a target="_blank" href="http://www.nonoidea.com/2012/12/12/html5%E7%9A%84%E6%98%8E%E5%A4%A9-%E5%B1%80%E9%83%A8%E6%9C%89%E5%B0%8F%E9%9B%A8/">http://www.nonoidea.com/2012/12/12/html5%E7%9A%84%E6%98%8E%E5%A4%A9-%E5%B1%80%E9%83%A8%E6%9C%89%E5%B0%8F%E9%9B%A8/</a>，由于作者本身并不是专业搞HTML5的技术专家，而且他自己也很坦诚的说了这文章是在【最近对HTML5产生兴趣, 做了粗浅的研究, 并和硅谷的两位玩弄此道多年的技术大佬电话交流】之后写下的，所以我看后第一时间也没有太去较真，只是在微博上说了一句“精神可嘉”。<br />而且客观来说，这篇文章写的真的很不错，文中的结论（或称作观点）很多我也是非常认可，例如<br /><div class="quote_title">引用</div><div class="quote_div">* 在移动端是否采用HTML5技术, 取决于你的产品形态<br />* 将来可能90%的应用会是HTML5, 而那10%, 可能永远也不适合HTML5<br />* HTML5性能的提升很大程度上将取决于低耗电高性能CPU/内存的出现, 或者电池技术的极大改善。</div><br /><br />但是不错的结论 却掩盖不了得出这个结论的过程（论据和原因）中所出现的一些疏漏和错误。<br />而后来看到很多转发和评论的人在认可结论的时候，连带那些错误的东西也一并认同（甚至主要就是认同那些错误的东西）， 我觉得我不能再沉默了，因为人们对HTML5的误解已经很多，不能再多下去啊。<br /><br /><br />首先声明，我不是HTML5黑，也绝对不是HTML5红橙黄绿青蓝紫什么乱七八糟的东西，我就是一个靠写代码吃饭的人，什么代码我写着顺手，我就用什么。我用HTML5开发应用或游戏，绝对不是HTML5有多牛逼，而是因为目前我用JS+HTML+CSS这个组合最熟练，仅此而已。另外，我在后面不会详细去区分HTML JS CSS, 都统一叫做HTML或HTML5了,请咬文嚼字党放我一条生路，夹着鸡鸡跪谢了。声明完毕，正文开始。<br /><br />=============================<br /><br /><br /><br />《HTML5的明天--局部有小雨》（以下简称 H文，请读者将其和H文学相区分）一文的内容大体如下：<br /><div class="quote_title">引用</div><div class="quote_div">1 HTML5是什么<br />2 HTML5的现状和优劣<br />3 HTML5的明天会如何</div><br /><br />这个基本上是任何介绍、点评、分析HTML5的（或其他任何技术）文章的标准结构，无任何不妥。<br />但是H文中每一部分都有一些值得商榷的地方。<br /><br /><br />首先，在HTML5是什么一节当中， 作者无视了HTML5的8大特性，反而把HTML5中微不足道的一些小功能点当做主要内容来写。如果大家真的对HTML5感兴趣，但是又没有时间去仔细的阅读HTML5官方规范，又不相信google和百度的搜索结果，那么至少应该去 W3C官方的HTML5主题页上去看一下，对HTML5的8大特性有所了解，主题页地址：<a target="_blank">htt://www.w3.org/html/logo/</a><br /><br />网页里用很清晰明了的说明了什么是HTML5以及HTML5带来的主要的新特性。<br /><br />=============================<br /><br /><br /><br />而在HTML5现状中，作者引用了一个数据“App Store上超过50%的应用已经是用HTML5来开发”，我实在不知道这个统计是怎么来的。但是不可否认的是，最近一年以来App Store上基于Hybrid开发的应用确实越来越多了。我的ios设备里就有几十款HTML5开发的网页向的手机游戏，不过目测在浩如烟海的App当中，HTML5应用应该不到50%，不过我也拿不出证据，在这里就不明确表态了。<br /><br />在对HTML5优点的表述中，作者主要提及了“跨平台”这个特性，也没什么不妥，只能说不够全面。<br /><br />=============================<br /><br /><br /><br />接下来到了H文中篇幅最大，也是问题最多的部分：HTML5的缺点。<br />作者主要描述了两类问题：一个是性能问题，一个是对HTML5支持度的问题。<br />H文的作者用大量文字来描写了关于线程的问题， 主要想告诉读者“HTML5性能低，因为不支持多线程”。<br /><br />关于这点网上已经有很多人指出了问题，作者也在后面加入了补充说明，但是我觉得作者可能还是没有理解到“HTML不支持多线程”的关键。<br /><br />“HTML 不支持多线程”绝对不是缺点，而是特点。关于HTML的单线程特点 以及工作原理网上有很多介绍文章, 如果大家没时间看相关文档,没时间自己动手体会, 可以看一下这个简短的 slide [url]http://www.slideshare.net/nzakas/high-performance-javascript-capitoljs-2011<br />[/url] (可以从第19页开始看).<br /><br />简单来说, 浏览器运行时,就好像(只是好像)下面这个无限循环:<br /></span><br /><pre class="java" name="code">while(true){
	1 更新数据和对象状态
	2 渲染可视化UI
}
( 而在需要异步的地方,HTML是提供了异步机制的,例如网络传输 事件响应 )
</pre><br /><span style="font-size: medium;"><br />1 2这两项工作,浏览器同一时间只能做一件. 这种单线程模型在满足用户使用需求的同时,也保证了开发方式的最简化,总的说来就是"简单够用".<br /><br />也许有人会质疑, 怎么可能够用? 可能对于大多数人来说,都会觉得多线程很牛逼，单线程很无力，其实不然，举个简单的例子： 目前大家玩到的大多数游戏（甭管它多华丽）的主体部分都是单线程编写的。事实上，在开发游戏时，很少用到多线程技术。<br /><br />游戏的核心逻辑其实也是一个循环体:<br /></span><br /><pre class="java" name="code">while(true){
	处理用户输入
	更新数据和对象状态
	渲染游戏画面
}</pre><br /><span style="font-size: medium;"><br />我们玩游戏时,满屏幕的敌人,乱飞的子弹, 天空飘过的白云...这一切的一切都是在一个线程里,<br />这个线程同样是同一时刻只做一件事.<br />华丽流畅的游戏 单线程模型都ok, 一个区区的网页和应用有何不可?<br /><br />而且,其实很多原生技术在处理数据的更新和渲染时, 用的也是类似的单线程方式(即使这个语言或技术支持多线程)。<br /><br />所以,HTML5性能确实是低(其实也没想象的低,所以才有那么多的HTML5游戏诞生),但是造成这个问题的原因不是单线程, 而是在主循环体内<br /></span><br /><pre class="java" name="code">while(true){
	1 更新数据和对象状态
	2 渲染可视化UI
}</pre><br /><span style="font-size: medium;"><br />这两项的性能还不够高. <br />我觉得要提高HTML5的性能,不应该靠"引入多线程"来实现, 应该靠"提升单线程内处理每一项时的性能"（以及如何将大量的第一项里的工作分解）来实现.<br />而WebWorker 的引入, 其实就是为了提高 第1项的性能.<br /><br />WebWorker 本身并不是传统的Thread模型,虽然底层是多线程实现的,但是它并没有引入同步锁 线程调度一类高级特性, 而是用简单的消息机制尽可能的保持了和单线程之间的匹配度.<br />换言之, WebWorker 并不是给单线程的 HTML带来的多线程特性, 而是给单线程的HTML带来了后台计算的能力.<br /><br />有点说远了,回到主题。我的核心观点就是：HTML5性能虽然低，但和多线程 单线程什么的无关，单线程也绝对不是HTML5的致命伤，而是即有好处也有坏处的一个特性。<br /><br />再来说说HTML5特性的普及度，WebWorker WebSocket （iOS 6 的safari已经支持这两个特性了）一类的HTML5特性其实正在被越来越多的浏览器支持，在移动端也是如此。相信未来这个不会是大的问题。<br /><br />H文最后关于未来那段说的也没什么问题。但我个人更倾向于“即使这一天到来了, 仍然会有至少10%的APP无法应用HTML5来实现”。<br /></span><br /><br />=============================<br /><br /><br /><br /><span style="font-size: large;"><span style="color: blue;">说了这么多我对H文的看法， 那么我再补充两句，来说说我个人对HTML5技术的看法吧。<br />简单说来，我觉得HTML5面临的主要问题就是： ”性工能“障碍。所谓“性工能”即：【性】能、【工】具、【能】力。</span><br /></span><br /><br /><span style="font-size: medium;"><br /><span style="color: blue;">性能低下</span>，这个事情基本上大家能够达成共识，至少和各种强大的Native展现层技术相比，确实有差距。但是这个问题不是致命的根本性问题。<br />当年Doom3 孤岛危机1 这些游戏出来时，也都是当时的硬件杀手，但是后来随着硬件的提升，性能问题也渐渐不再是核心问题了（这两个游戏在FPS游戏里，是真不好玩啊）。<br />换言之，当市场上对性能要求高的 好的产品和应用越来越多时，那些底层（浏览器 os 硬件）厂商不会坐视不理的，因为这对于他们来说 也是机会。<br />所以作为HTML前端工程师，我们所要做的就是尽可能的优化自己的代码，但不要被性能束缚了产品的手脚，同时在保证自己代码质量和算法没问题的情况下，行动+呼吁+等待就OK了。 <br />当然,不要强迫HTML5去做不应该它来做的事情。<br /><br /><span style="color: blue;">工具匮乏</span>，从开发调试到测试维护整个过程中，确实缺少强有力的工具。这个问题在可预见的未来，应该还是比较难解决，不过对成熟的HTML开发团队而言，似乎也不是大问题，因为大家已经比较习惯和适应现在的开发环境和方式了。但是对于围绕上层应用所需要的辅助工具确实欠缺。拿HTML5游戏来说：地图编辑器、精灵编辑器、粒子效果、游戏脚本编辑器、音效管理工具、性能监控...等等,虽然理论上开发这些并不难,很多公司也都在尝试开发自己的基础架构,但是和unity3d flash这些比起来,还是太弱了.期待 cocos2d-x能够为我们带来不一样的局面(此处为植入广告,请林顺 王哲自行考虑所需费用)。 <br />总之，HTML5为web应用带来了更多新的形式，不过围绕这些新形式的相关辅助工具确实还很欠缺。但是，未来可期。<br /><br /><span style="color: blue;">能力不足</span>，这个主要是指HTML5本身的定位和它的原则导致有很多事情是它根本做不了的。举个极端点的例子，你希望在网页里借助HTML5技术来格式化你的U盘、刻录一张CD几乎是不可能的（谁知道 HTML6789时会不会提供一组Disk API呢？）。因为很多事情根本就不在HTML的发展蓝图里。而且浏览器根本的目的是为了保证用户可以高效便捷安全的网上冲浪，这个根本目的导致了浏览器本身会存在一些制约，例如安全性上的。所以，指望HTML5能完全取代Native是不可能的，至少我觉得在我退休之前是不可能的。<br /><br />在一些WebOS里，js似乎很强大，能做很多底层的事情，但是其实这些东西本质上已经不是标准化的HTML技术了，而是通过WebOS厂商定制的特殊环境和专有API实现的，这些东西显然超出了本文的讨论范围之内。<br /><br /><br /><br />以上不难看出， 当未来性能和工具都不是问题时， ”能力“依然会是制约HTML5应用的一道枷锁，而且是最顽固的一个。<br />JS作为一种脚本语言, 本身对使用场景并没有什么限制, 它可以出现在浏览器里, 也可以出现在server后台,甚至有一天出现在智能电器 嵌入式设备里也都完全正常, 但是这不意味着HTML(HTML CSS JS)就能做所有事情,就能够取代Native.<br />所以我个人反复强调过我的一个观点： Hybrid技术绝对不是过渡技术, 它的生命力会很强.因为它是一个兼容并包的技术,是一个真正可以沟通起HTML和Native的桥梁. 只要Native和HTML不完全相同,那么Hybrid就有存在的价值.<br /><br />=============================<br /><br /><br /><br />我发现这篇文章我又写散了, 主题凌乱, 难以总结出中心思想，那我自己来总结一下吧：<br />HTML5技术本身确实还有很多问题，但是未来值得期待————只是这种期待要适当，否则最后的失望不可避免。HTML5是一场伟大的技术变革，也许真的可以改变世界，但是在改变世界之前，先试着改变自己，而改变自己，先从改变自己对待HTML5的态度开始吧。<br /><br /><br />-- OVER --<br /><br /><br /><br /></span><br /><br />
              
              <br/><br/>
              <span style="color:red;">
                <a href="http://fins.iteye.com/blog/1747321#comments" style="color:red;">已有 <strong>9</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
              </span>
              <br/><br/><br/>
<span style="color:#E28822;">ITeye推荐</span>
<br/>
<ul><li><a href='/clicks/433' target='_blank'><span style="color:red;font-weight:bold;">—软件人才免语言低担保 赴美带薪读研！— </span></a></li></ul>
<br/><br/><br/>
              ]]>
            </description>
            <pubDate>Thu, 13 Dec 2012 18:08:14 +0800</pubDate>
            <link>http://fins.iteye.com/blog/1747321</link>
            <guid isPermaLink="false">http://fins.iteye.com/blog/1747321</guid>
          </item>
                  <item>
            <title>苹果真的要在 AppStore 里封杀 WebApp 吗? </title>
            <description>
              <![CDATA[
              <span style="font-size: medium;"><br />苹果真的要在 AppStore 里封杀 WebApp 吗 ?<br /><br />最近几个月, 苹果AppStore似乎加强了对WebApp的管控, 很多过去能上架的 使用WebApp+Native壳的应用陆陆续续的都被拒了.<br /><br />于是 很多人开始抛出了"苹果要封杀WebApp"/"苹果要像当初对待Flash一样对HTML5说不"一类的观点.<br /><br />作为一个HTML5开发人员 + 苹果产品用户, 我也想表达一下自己对这个问题的看法.<br />我的观点不一定对 但是,即使我错了,也不能证明那些认为"苹果要封杀WebApp"的荒谬观点是正确的(好流氓 哈哈).<br /><br />先来看一看让广大HTML5/WebApp开发者 感动忧虑的那段苹果的原文吧:<br /><br /><div class="quote_title">引用</div><div class="quote_div">If you cannot – or choose not to – revise your app to be in compliance with the App Store Review Guidelines, you may wish to build an HTML5 web app instead. You can distribute web apps directly on your web site;<strong> the App Store does not accept or distribute web apps</strong>.</div><br /><br />简单说就是一句话: 如果你的应用是一个Webapp, 那么请以网页的形式发布你的产品就好了, 不要放到AppStore里, AppStore不接收WebApp.<br /><br />不管怎么看 我都看不出来"苹果要封杀WebApp"的意思, 更看不出有些人YY的"苹果因为担心HTML5太强大了抢了Native的市场"这种观点.<br /><br /><br />相反 我觉得苹果是在引导WebApp用正确的方式去发行: 如果你的应用在网页里也能跑, 但你却非要放到AppStore里, 结果就是赚了钱还要分给苹果30%, 而且更新升级什么的还要走漫长的审核过程,何苦呢?<br /><br />在AppStore方面, 苹果是靠应用(注意,是应用,而不是和某种具体技术绑定的应用.只要是合法的 好的应用,受欢迎卖得多,苹果都能赚钱,苹果才不关心应用用的是什么技术呢)分成赚钱, 如果纯粹从经济目的出发, 苹果完全没必要把WebApp从他能赚钱的领域(AppStore应用)驱赶到他不能赚钱的领域(Web浏览器). <br /><br /><br />所以 一个合法的应用被拒绝的原因笼统的说只有三点: 1 违规(调用不该调用的方法,做了危险的事情,山寨抄袭等等) 2 苹果觉得应用不够好 3 觉得放到AppStore里不合适.<br /><br />前两点不用说大家都懂, 而最后一点我想是大量WebApp被拒绝的一个主要原因: 完全没有使用或者没必要使用任何Native的技术,在网页里也能跑. 通常这种应用只是把AppStore当做一个发行渠道.<br /><br />我特意去AppStore上搜索了下, 其实存在大量的Phonegap封装的应用, 我挑了几个免费的下来,解包看了一下, 它们都使用到了Phonegap提供的一些只有native技术才能实现的功能, 我想这是他们能通过审核的一个很重要的原因之一.<br /><br />=========================<br />还有朋友提出了这样一个观点:"app store的意义是维护苹果利益，webapp可以同时存在多个平台，就会降低apple独占的市场份额，直接影响利益。"<br /><br />我是非常不赞同这种观点的. 把Webapp同时存在于多个平台 和 apple的利益 挂钩, 显然是套用了当年iOS和Flash之间的故事. 但两者完全没有可比性.<br /><br />当年Flash是想在浏览器里跑, 而苹果驱逐了它.<br />WebApp想进入AppStore , 苹果建议它去浏览器里跑.<br /><br />一个是驱逐, 一个是换个地方跑, 完全不一样.<br />当然 你可以说, 以后HTML5足够强大了, 苹果也许也会把WebApp驱逐.<br />这么久远的事情到底会不会发生 我不知道, 但是我觉得,如果HTML5真的强大到和Flash一样牛逼, 苹果大可选择把WebApp赶回AppStore的策略, 这样才满足利益最大化啊.<br /><br />另外 我希望这位朋友你不妨思考思考如下几个问题(会用到反问,但绝对没有不敬之意):<br />1)如果你是苹果,难道你不希望从自己平台诞生的应用,能红遍全球吗?就像愤怒的小鸟一样成为一种现象.<br />2)如果你是苹果,难道你不希望其他平台热门的应用能早日降临到自己的iOS上吗?<br />3)你觉得在智能移动设备上, 走传统游戏主机那种"独占游戏"的路能走得通吗?你觉得"因为某某应用只有iPhone有安卓没有,所以我要买iPhone"这样的事情发生的几率很大吗?<br /><br />====================<br /><br />越说越散了,&nbsp; 该收收尾了. 最后总结一下吧.<br /><br />我也承认, AppStore有很多过分的要求, 但是这些绝对不是针对HTML5和WebApp来的.<br />(例如 禁止远程修改代码, 禁止绕过appstore直接内部更新版本等等)<br />所以我们没有必要因为几个WebApp被拒就对HTML5在iOS平台上的未来感到担忧.<br /><br />iOS系统作为对HTML5支持最好的移动平台, 我们没有理由怀疑它对HTML5的态度.<br />我想,苹果加强对AppStore内WebApp的管理力度, 根本原因只是为了保证AppStore的质量. <br /><br />当然在整个事件中,苹果也有做的不妥的地方, 他始终没有针对webapp/ Hybrid技术构建的应用提出一个具体的 有章可循的规则说明,给人一种"法无定法"的感觉.<br />但是随着Hybrid技术和HTML5技术的发展, 我想 苹果会对这个问题慢慢重视起来.<br /><br /><br /><br /><br /><br /><br /><br /><br /></span>
              
              <br/><br/>
              <span style="color:red;">
                <a href="http://fins.iteye.com/blog/1685886#comments" style="color:red;">已有 <strong>5</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
              </span>
              <br/><br/><br/>
<span style="color:#E28822;">ITeye推荐</span>
<br/>
<ul><li><a href='/clicks/433' target='_blank'><span style="color:red;font-weight:bold;">—软件人才免语言低担保 赴美带薪读研！— </span></a></li></ul>
<br/><br/><br/>
              ]]>
            </description>
            <pubDate>Wed, 26 Sep 2012 16:30:47 +0800</pubDate>
            <link>http://fins.iteye.com/blog/1685886</link>
            <guid isPermaLink="false">http://fins.iteye.com/blog/1685886</guid>
          </item>
                  <item>
            <title>说说这次关于Apple开发者帐号的&quot;微投资&quot;</title>
            <description>
              <![CDATA[
              <span style="font-size: medium;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 说说这次关于Apple开发者帐号的"微投资"<br /><br />昨天我在微博上发了这样一条消息：<br />"<br />&nbsp; 我想找人资助我购买一个 apple 的开发者帐号(99美金) 然后未来一年内，我赚的钱和资助者五五分。风险就是我可能一分钱也赚不到。会有人愿意资助吗？<br />"<br />有很多朋友表示愿意资助，也有人表示不理解。<br /><br />首先对愿意资助我的朋友表示感谢，谢谢你们的热情以及对我的信任。然后，我觉得我很有必要说一下我发这条消息的动机和目的，让不理解我的人能稍微的理解我，让理解我的人能更好的理解我。<br /><br />----------------------------<br />我今年30了，但是很多时候幼稚得像13——例如我还相信那些叫做梦想的东西——虽然我事业不算成功，无房无车无存款，但工作还算不错薪水也不低，而且我本人消费观念一向比较凶猛，所以真的不是因为拿不出钱 也不是舍不得花这份钱(你以为"就是拿不出、 就是舍不得"这种事情我会告诉你吗 =,.= )。我这么做，很大程度上是为了寻找一份"亏欠"。<br /><br />虽然我不是一个专业的iOS开发者，但是随着HTML5和Hybrid技术在iOS平台上的日趋成熟，我总觉得自己如果不去试一试实在是太浪费自己的才能了，所以那颗蠢蠢欲动的心里从未停止过不切实际的欲望。不过我很了解自己，我和大多数人一样，总是能给自己的懒惰找到很多的借口和理由。所以我真的不确定自己如果踏上iOS开发者这条路，能够走多远。<br /><br />也许很多人都会说："帐号也不贵，你也有相关的设备，买一个玩玩呗，如果走不下去就不玩了，反正也没什么损失 就当作一次锻炼好了。而且运气好也许还能赚钱，另外……还有……如果……balabalabalabalabala……"。是的，我也有过这种想法。但是有句俗话说的好：书非借而不能读也。虽然用到这里并不是很合适，但是它所阐述的道理是通用的：有些东西，一旦是你自己的了，你反而不会珍惜。<br />所以，我希望找人资助(我觉得资助比投资跟<br />合适一些)我，很大程度上是希望我能多一份亏欠，从而多一份动力和责任。<br />每当我想放弃的时候，会提醒自己：喂，这可是某某某给你买的啊，你就这样放弃了 对得起TA吗？同时，99美元的亏欠又不至于让我背上太多的压力。<br /><br />在这里，感谢@IDG郑兰，谢谢你给了我我想要的亏欠。我所能做的，就是努力的在一年后让自己觉得不再亏欠你什么。<br /><br />----------------------------<br />关于"资助99美金和55分成"的设定，有很多朋友认为这么分我太不划算了。其实我觉得很划算，因为这个设定很大程度上是因为我对自己的自知之明。<br />我是个技术人员，即使我是宇宙第一牛逼的技术人员，我也不敢保证自己能开发出赚钱的应用。<br />而且第一年搞iOS开发，在海量的应用里面，在已经成为常态的刷榜面前，我能赚钱的几率很低，而且我还会坚持一些自己希望坚持的东西(这些东西和商业也许是冲突的，例如开发一些自己喜欢 但是别人不太可能喜欢的东西)。<br />所以用55 37 46 还是28 19的分发去分0，结果都是一样的，对吧。而假使我足够幸运还真的赚了点钱，估计也不会多，钱不多时，怎么分成同样意义不大。<br /><br />我要再次强调一遍，不要把这种#微投资#和创业拉投资一类严肃的事情联系起来，也不要要求我做"充分展示自己的才干 出具完备的商业计划"一类的事情，我也不会去做赚钱的承诺。当然，我也不是在儿戏，我能给出的承诺是：未来一年内 至少发布1款付费应用，2款免费应用，同时尽力给投资者一份继续投资我且投资更多钱的信心。<br /><br />-----------------------------<br />昨天发布这个#微投资#需求后，见到很多人愿意投资我，在激动和感动的同时，我也在想，其实热心的 愿意出一点小钱帮助开发者的人真的很多。<br />而在中国更是不缺少有才华有想法的程序员，但是很多程序员也许真的被苹果生态系统开发的经济门槛吓住了，尤其是那些最有活力的学生们。如果有更多的朋友愿意去"资助(或者借给)一位靠谱的学生一台mac mini+一台iPod touch+一个开发者帐号，给他们一个创造奇迹的机会"（并有合理的分成），我想我们的App市场一定会发生一些好的改变，也许不会变得更赚钱，但一定会更有趣。<br />如果你有去做这种"低投入,高风险"的资助的愿望，去试着发现身边靠谱的人吧，如果找到了，记得告诉我一下，让我也分享一下你们的喜悦。<br /><br />最后，不管怎样，这种低投入高风险的投资行为都是蛮怪异的，所以大家就先把它当做"一次微投资的行为艺术"好了。<br /><br /></span>
              
              <br/><br/>
              <span style="color:red;">
                <a href="http://fins.iteye.com/blog/1683526#comments" style="color:red;">已有 <strong>2</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
              </span>
              <br/><br/><br/>
<span style="color:#E28822;">ITeye推荐</span>
<br/>
<ul><li><a href='/clicks/433' target='_blank'><span style="color:red;font-weight:bold;">—软件人才免语言低担保 赴美带薪读研！— </span></a></li></ul>
<br/><br/><br/>
              ]]>
            </description>
            <pubDate>Sat, 22 Sep 2012 16:23:10 +0800</pubDate>
            <link>http://fins.iteye.com/blog/1683526</link>
            <guid isPermaLink="false">http://fins.iteye.com/blog/1683526</guid>
          </item>
                  <item>
            <title>聊聊 iOS 5 和 iOS 6 在HTML5 canvas渲染上的差异</title>
            <description>
              <![CDATA[
              我录制了一段iphone4s 下 ios 5 和 ios 6 的 canvas性能对比视频<a target="_blank" href="http://t.cn/zlvnKZk">http://t.cn/zlvnKZk</a> 通过这个视频 我们可以发现很多有趣的事情. 简单来说iOS 6 的特点就是 : 以退为进, 为了更好的体验,而减速 !!!! 未来 A6芯片+ iOS6 下的HTML5体验一定会很赞!<br /><br />视频地址:&nbsp; <a target="_blank" href="http://v.youku.com/v_show/id_XNDQ5OTY1ODk2.html">http://v.youku.com/v_show/id_XNDQ5OTY1ODk2.html</a><br /><br />javaeye怎么不能潜入flash视频了?<br /><br /><br /><br />下面说说我的看法.<br /><br /><br />视频中白色的是iOS 5 , 黑色的是 iOS 6 gm版(相当于正式版).<br />首先对这个视频里的测试页面做一下说明.<br />测试页面地址 :&nbsp; <a target="_blank" href="http://tryhtml5.sinaapp.com/op/logo.html">http://tryhtml5.sinaapp.com/op/logo.html</a><br />测试用例的特性:<br />基于canvas, 画面背景是一张彩虹色的大图, <br />前景是 180个(6种)logo图片,图片大小在500*500左右,渲染时, 缩小+移动+旋转<br /><br />logo在移动时采用的是 固定步长. 也就是每次loop时,logo移动的像素数量是固定的,与每次loop的间隔时间无关.(这点很重要)<br /><br />在视频中,我们可以发现如下特点:<br /><br />iOS 5 里 logo移动的快, 但是不顺畅, 一跳一跳 一卡一卡的.<br />iOS 6 里的则相反, logo移动的速度相对慢一些, 但是更顺滑.<br /><br />logo移动快慢大家可以通过计时(某一行logo移动一个来回需要的时间),或者是对比着看,同一行logo, 在iOS 5上会逐渐拉开iOS 6上的logo.<br /><br />=====================<br /><br />在谈论iOS 6带来的这种"改变"的之前, 先来说一说在canvas渲染时, 整个浏览器的一个内部流程.<br /><br />实现一个canvas动画在完美情况下( 60FPS ), 一秒钟内, 浏览器是做了如下事情<br /><br />1 运行js代码,更新canvas的imageData数据<br />2 根据canvas里最新的imageData去渲染画面<br />3 1到2重复60次<br /><br />完美情况下 上面的工作可以顺利的进行. 浏览器的js线程和ui渲染线程是互斥的,同一时刻只能做一件事情.<br />那么当渲染画面成为瓶颈的时候,一切就不是如此了.<br /><br /><br />一种处理方案是:等待每一次渲染的完成 再进行下一次工作.<br />这样在一秒内, js执行的次数 == 渲染的次数 &lt; 60 <br /><br />另一种方案是:系统有选择的放弃掉<span style="color: blue;">【若干渲染】</span>, 从而<span style="color: blue;">【保证js】</span>的执行次数受到尽可能小的影响.<br />那么在一秒内, 渲染的次数 &lt; js执行的次数 &lt; 60 <br /><br />通常情况下 渲染性能无论多高,都会低于js执行的性能的, 所以当渲染跟不上计算时，通常会选择第二种方案.<br /><br />=====================<br /><br />下面 我们来根据视频猜测一下---- 真的只是猜, 真实原因只有safari工程师自己出来说才行,否则我只能猜, 我知道这样是不严谨的, 根据现象猜原因是错误的, 但是, 对不起, 就让我错一次吧。<br /><br /><br />第二种方案中, 最终效果的好坏，则取决于放弃<span style="color: blue;">【若干渲染】</span>, 里的若干到底是多少, 以及<span style="color: blue;">【保证js】</span>运行 要保证到什么程度, 系统需要在这两方面做出权衡。<br /><br />但是一个简单的原则就是 : 渲染能力越低，需要放弃的渲染越多， 渲染能力越高，需要放弃的越少。<br /><br /><br />通过视频我们可以看出, <br />iOS5 里为了保证js的运行， 放弃掉了很多渲染， 但是js执行的次数几乎没有受到影响。<br />而iOS 6则大大减少了放弃掉的渲染(顺滑了很多), 而同时,js的运行只受到了微小的影响(但还是受到了一些影响).<br /><br />同时, 提高渲染速度,适当降低js权重,这也使得用js记录FPS的方式比以前准确了很多.<br /><br /><br />但综合来看, iOS6的调整对整体的体验带来了巨大的提升, 同时iOS 6能够做出这种调整,很可能是因为渲染能力的提升使得它可以勇敢的选择放弃更少的渲染.<br />（如果iOS5 里采用iOS6的策略，结果可能是双输：js次数得不到保证，渲染也得不到什么提升）<br /><br /><br /><br /><br />另, 有朋友说 iOS 5里丢帧是bug (因为android里面有这个bug) ,但是我不同意这种观点, 因为了解iOS 5的朋友应该清楚, iOS 5的canvas里已经引入了硬件加速, 它的canvas性能和表现力 在当时已经是逆天的了. 这么优秀的平台不太可能有这么低级的bug. 而且,如果是bug,它出现的频率和严重性也不应该有如此严重的人工干预的痕迹啊. <br />换句话说: "渲染压力不大时,完美渲染,&nbsp; 渲染压力加大时,放弃掉一些渲染以保证程序的运行" 这个怎么看都像是策略而不是bug啊.<br /><br /><br /><br />===========<br />本文很多观点基于猜测， 欢迎大家来拍砖！<br /><br /><br /><br /><br />
              
              <br/><br/>
              <span style="color:red;">
                <a href="http://fins.iteye.com/blog/1678088#comments" style="color:red;">已有 <strong>0</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
              </span>
              <br/><br/><br/>
<span style="color:#E28822;">ITeye推荐</span>
<br/>
<ul><li><a href='/clicks/433' target='_blank'><span style="color:red;font-weight:bold;">—软件人才免语言低担保 赴美带薪读研！— </span></a></li></ul>
<br/><br/><br/>
              ]]>
            </description>
            <pubDate>Thu, 13 Sep 2012 18:40:47 +0800</pubDate>
            <link>http://fins.iteye.com/blog/1678088</link>
            <guid isPermaLink="false">http://fins.iteye.com/blog/1678088</guid>
          </item>
                  <item>
            <title>谈谈&quot;求线段交点&quot;的几种算法(js实现,完整版) </title>
            <description>
              <![CDATA[
              <span style="font-size: x-large;">谈谈"求线段交点"的几种算法(js实现,完整版)</span><br /><br />"求线段交点"是一种非常基础的几何计算, 在很多游戏中都会被使用到.<br />下面我就现学现卖的把最近才学会的一些"求线段交点"的算法说一说, 希望对大家有所帮助.<br />本文讲的内容都很初级, 主要是面向和我一样的初学者, 所以请各位算法帝们轻拍啊 嘎嘎<br /><br /><div class="quote_title">引用</div><div class="quote_div">已知线段1(a,b) 和线段2(c,d) ,其中a b c d为端点, 求线段交点p .(平行或共线视作不相交)</div><br /><br />===============================<br /><strong><span style="font-size: x-large;"><span style="color: blue;">算法一</span></span>: 求两条线段所在直线的交点, 再判断交点是否在两条线段上.</strong><br /><br /> 求直线交点时 我们可通过直线的一般方程 ax+by+c=0 求得(方程中的abc为系数,不是前面提到的端点,另外也可用点斜式方程和斜截式方程,此处暂且不论). <br /> 然后根据交点的与线段端点的位置关系来判断交点是否在线段上. 公式如下图:<br /><br /><img src="http://dl.iteye.com/upload/picture/pic/112455/f82ab86e-e0fe-396f-b9ab-4d2bdcfca9d9.png" /><br /><br /> 实现代码如下 : <br /><br /><pre class="javascript" name="code">
function segmentsIntr(a, b, c, d){

/** 1 解线性方程组, 求线段交点. **/
// 如果分母为0 则平行或共线, 不相交
    var denominator = (b.y - a.y)*(d.x - c.x) - (a.x - b.x)*(c.y - d.y);
    if (denominator==0) {
        return false;
    }
 
// 线段所在直线的交点坐标 (x , y)    
    var x = ( (b.x - a.x) * (d.x - c.x) * (c.y - a.y) 
                + (b.y - a.y) * (d.x - c.x) * a.x 
                - (d.y - c.y) * (b.x - a.x) * c.x ) / denominator ;
    var y = -( (b.y - a.y) * (d.y - c.y) * (c.x - a.x) 
                + (b.x - a.x) * (d.y - c.y) * a.y 
                - (d.x - c.x) * (b.y - a.y) * c.y ) / denominator;

/** 2 判断交点是否在两条线段上 **/
    if (
        // 交点在线段1上
        (x - a.x) * (x - b.x) &lt;= 0 &amp;&amp; (y - a.y) * (y - b.y) &lt;= 0
        // 且交点也在线段2上
         &amp;&amp; (x - c.x) * (x - d.x) &lt;= 0 &amp;&amp; (y - c.y) * (y - d.y) &lt;= 0
        ){

        // 返回交点p
        return {
                x :  x,
                y :  y
            }
    }
    //否则不相交
    return false

}
</pre>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br /><br />算法一思路比较清晰易懂, 但是性能并不高. 因为它在不确定交点是否有效(在线段上)之前, 就先去计算了交点, 耗费了较多的时间.<br />如果最后发现交点无效, 那么之前的计算就白折腾了. 而且整个计算的过程也很复杂.<br />那么有没有一种思路,可以让我们先判断是否存在有效交点,然后再去计算它呢? <br />显然答案是肯定的. 于是就有了后面的一些算法.<br /><br /><br />===============================<br /><strong><span style="font-size: x-large;"><span style="color: blue;">算法二</span></span>: 判断每一条线段的两个端点是否都在另一条线段的两侧, 是则求出两条线段所在直线的交点, 否则不相交.</strong><br /><br />第一步判断两个点是否在某条线段的两侧, 通常可采用投影法:<br /><br />求出线段的法线向量, 然后把点投影到法线上, 最后根据投影的位置来判断点和线段的关系. 见下图<br /><br /><img src="http://dl.iteye.com/upload/picture/pic/112457/4fd647af-eac5-3b4d-9eda-17bf979df7ba.png" /><br /><br />点a和点b在线段cd法线上的投影如图所示, 这时候我们还要做一次线段cd在自己法线上的投影(选择点c或点d中的一个即可).<br />主要用来做参考.<br />图中点a投影和点b投影在点c投影的两侧, 说明线段ab的端点在线段cd的两侧.<br /><br />同理, 再判断一次cd是否在线段ab两侧即可.<br /><br />求法线 , 求投影 什么的听起来很复杂的样子, 实际上对于我来说也确实挺复杂,在几个月前我也不会(念书那会儿的几何知识都忘光了 :'( )'<br />不过好在学习和实现起来还不算复杂, 皆有公式可循:<br /><br /><br />求线段ab的法线:<br /><br /><pre class="javascript" name="code">
var nx=b.y - a.y, 
    ny=a.x - b.x;
var normalLine = {  x: nx, y: ny };
</pre><br /><br />注意: 其中 normalLine.x和normalLine.y的几何意义表示法线的方向, 而不是坐标.<br /><br /><br />求点c在法线上的投影位置:<br /><pre class="javascript" name="code">
var dist= normalLine.x*c.x + normalLine.y*c.y;
</pre><br /><br />注意: 这里的"投影位置"是一个标量, 表示的是到法线原点的距离, 而不是投影点的坐标.<br />通常知道这个距离就足够了.<br /><br />当我们把图中 点a投影(distA),点b投影(distB),点c投影(distC) 都求出来之后, 就可以很容易的根据各自的大小判断出相对位置.<br /><br />distA==distB==distC 时, 两条线段共线<br />distA==distB!=distC 时, 两条线段平行<br />distA 和 distB 在distC 同侧时, 两条线段不相交.<br />distA 和 distB 在distC 异侧时, 两条线段是否相交需要再判断点c点d与线段ab的关系.<br /><br />前面的那些步骤, 只是实现了"判断线段是否相交", 当结果为true时, 我们还需要进一步求交点.<br />求交点的过程后面再说, 先看一下该算法的完整实现 :<br /><br /><pre class="javascript" name="code">
function segmentsIntr(a, b, c, d){

    //线段ab的法线N1
    var nx1 = (b.y - a.y), ny1 = (a.x - b.x);

    //线段cd的法线N2
    var nx2 = (d.y - c.y), ny2 = (c.x - d.x);
    
    //两条法线做叉乘, 如果结果为0, 说明线段ab和线段cd平行或共线,不相交
    var denominator = nx1*ny2 - ny1*nx2;
    if (denominator==0) {
        return false;
    }
    
    //在法线N2上的投影
    var distC_N2=nx2 * c.x + ny2 * c.y;
    var distA_N2=nx2 * a.x + ny2 * a.y-distC_N2;
    var distB_N2=nx2 * b.x + ny2 * b.y-distC_N2;

    // 点a投影和点b投影在点c投影同侧 (对点在线段上的情况,本例当作不相交处理);
    if ( distA_N2*distB_N2&gt;=0  ) {
        return false;
    }
    
    //
    //判断点c点d 和线段ab的关系, 原理同上
    //
    //在法线N1上的投影
    var distA_N1=nx1 * a.x + ny1 * a.y;
    var distC_N1=nx1 * c.x + ny1 * c.y-distA_N1;
    var distD_N1=nx1 * d.x + ny1 * d.y-distA_N1;
    if ( distC_N1*distD_N1&gt;=0  ) {
        return false;
    }

    //计算交点坐标
    var fraction= distA_N2 / denominator;
    var dx= fraction * ny1,
        dy= -fraction * nx1;
    return { x: a.x + dx , y: a.y + dy };
}
</pre><br /><br />最后 求交点坐标的部分 所用的方法看起来有点奇怪, 有种摸不着头脑的感觉.<br />其实它和算法一 里面的算法是类似的,只是里面的很多计算项已经被提前计算好了.<br />换句话说, 算法二里求交点坐标的部分 其实也是用的直线的线性方程组来做的.<br /><br />现在来简单粗略 很不科学的对比一下算法一和算法二:<br />1 最好情况下, 两种算法的复杂度相同<br />2 最坏情况, 算法一和算法二的计算量差不多<br />3 但是算法二提供了 更多的"提前结束条件",所以平均情况下,应该算法二更优.<br /><br />实际测试下来, 实际情况也确实如此.<br /><br />前面的两种算法基本上是比较常见的可以应付绝大多数情况. 但是事实上还有一种更好的算法.<br />这也是我最近才新学会的(我现学现卖了,大家不要介意啊...)<br /><br />===============================<br /><strong><span style="font-size: x-large;"><span style="color: blue;">算法三</span></span>: 判断每一条线段的两个端点是否都在另一条线段的两侧, 是则求出两条线段所在直线的交点, 否则不相交.</strong><br /><br />(咦? 怎么感觉和算法二一样啊? 不要怀疑 确实一样 ... 囧)<br />所谓算法三, 其实只是对算法二的一个改良, 改良的地方主要就是 : <br />不通过法线投影来判断点和线段的位置关系, 而是通过点和线段构成的三角形面积来判断.<br /><br />先来复习下三角形面积公式: 已知三角形三点a(x,y) b(x,y) c(x,y), 三角形面积为:<br /><br /><pre class="javascript" name="code">
var triArea=( (a.x - c.x) * (b.y - c.y) - (a.y - c.y) * (b.x - c.x) ) /2 ;
</pre><br /><br />因为 两向量叉乘==两向量构成的平行四边形(以两向量为邻边)的面积 , 所以上面的公式也不难理解.<br />而且由于向量是有方向的, 所以面积也是有方向的, 通常我们以逆时针为正, 顺时针为负数.<br /><br />改良算法关键点就是:<br />如果"线段ab和点c构成的三角形面积"与"线段ab和点d构成的三角形面积" 构成的三角形面积的正负符号相异, <br />那么点c和点d位于线段ab两侧. 如下图所示:<br /><br /><img src="http://dl.iteye.com/upload/picture/pic/112459/4de37912-f58a-32c3-aaff-32c85ef8b11c.png" /><br /><br />图中虚线所示的三角形, 缠绕方向(三边的定义顺序)不同, 所以面积的正负符号不同.<br /><br /><br />下面还是先看代码:<br />由于我们只要判断符号即可, 所以前面的三角形面积公式我们就不需要后面的 除以2 了.<br /><br /><pre class="javascript" name="code">
function segmentsIntr(a, b, c, d){

    // 三角形abc 面积的2倍
    var area_abc = (a.x - c.x) * (b.y - c.y) - (a.y - c.y) * (b.x - c.x);

    // 三角形abd 面积的2倍
    var area_abd = (a.x - d.x) * (b.y - d.y) - (a.y - d.y) * (b.x - d.x); 

    // 面积符号相同则两点在线段同侧,不相交 (对点在线段上的情况,本例当作不相交处理);
    if ( area_abc*area_abd&gt;=0 ) {
        return false;
    }

    // 三角形cda 面积的2倍
    var area_cda = (c.x - a.x) * (d.y - a.y) - (c.y - a.y) * (d.x - a.x);
    // 三角形cdb 面积的2倍
    // 注意: 这里有一个小优化.不需要再用公式计算面积,而是通过已知的三个面积加减得出.
    var area_cdb = area_cda + area_abc - area_abd ;
    if (  area_cda * area_cdb &gt;= 0 ) {
        return false;
    }

    //计算交点坐标
    var t = area_cda / ( area_abd- area_abc );
    var dx= t*(b.x - a.x),
        dy= t*(b.y - a.y);
    return { x: a.x + dx , y: a.y + dy };

}
</pre><br /><br /><br />最后 计算交点坐标的部分 和算法二同理.<br /><br /><br />算法三在算法二的基础上, 大大简化了计算步骤, 代码也更精简. 可以说,是三种算法里, 最好的.实际测试结果也是如此.<br /><br />当然必须坦诚的来说, 在Javascript里, 对于普通的计算, 三种算法的时间复杂度其实是差不多的(尤其是V8引擎下).<br />我的测试用例里也是进行变态的百万次级别的线段相交测试 才能拉开三种算法之间的差距.<br /><br />不过本着精益求精 以及学习的态度而言, 追求一个更好的算法, 总是有其积极意义的.<br /><br /><br />好了 不啰嗦了, 就到这里吧.<br />现学现卖的东西, 难免有错误, 还请大家不吝斧正. 先谢谢啦 <br /><br /><br /><br />补充:<br />后来微博上@miloyip (这个是真正的大牛, 是会自己写3D引擎的人哦 )还推荐了另外一种更好的算法, 不过我还没有理解透彻.<br />等我学会了 再来和大家分享<img src="/images/smiles/icon_smile.gif" /><br /><br /><br /><br />(完)<br /><br /><br /><br /><br />
              
              <br/><br/>
              <span style="color:red;">
                <a href="http://fins.iteye.com/blog/1522259#comments" style="color:red;">已有 <strong>3</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
              </span>
              <br/><br/><br/>
<span style="color:#E28822;">ITeye推荐</span>
<br/>
<ul><li><a href='/clicks/433' target='_blank'><span style="color:red;font-weight:bold;">—软件人才免语言低担保 赴美带薪读研！— </span></a></li></ul>
<br/><br/><br/>
              ]]>
            </description>
            <pubDate>Thu, 10 May 2012 16:57:56 +0800</pubDate>
            <link>http://fins.iteye.com/blog/1522259</link>
            <guid isPermaLink="false">http://fins.iteye.com/blog/1522259</guid>
          </item>
                  <item>
            <title>有些事现在不做，一辈子都不会做了</title>
            <description>
              <![CDATA[
              <span style="font-size: medium;"><br /><br /><br />　　和当初那篇<a target="_blank" href="http://qing.weibo.com/1657422865/62ca441133000484.html">《Done is well done》</a>一样，这次注定仍然会是一篇形式大于内容的文章，里面不会有什么经验心得，有的只是我的絮絮叨叨。但是这都无所谓了，反正写在这里的每一句话，管他是大话空话废话假话客套话，都是我想说的话，这就足够了。<br /><br />=========================<br /><br />　　我一直都承认自己是一个极度猥琐的人，例如当我写下标题里的“做”字时，心里马上就开始浮想联翩了。我这种什么事情都会往龌龊之事上联想的人，往往也是思维异常活跃和发散的人。胡思乱想是我大脑运动的常态，每天都会有很多或是无聊的或是怪异的——偶尔也参杂一些还算正常的——想法在脑子里跳来跳去，但是它们始终都跳不到现实里——因为我找不到一个足够强大的理由，来说服自己去把这些想法一一实现。<br /><br />　　不知道从什么时候开始，无论做什么事情，都要去思考理由、代价、成本、收获…… 有人说，这是成熟的标志。也许确实如此吧，成熟和羁绊总是成正比的。当然，成熟没什么不好，只是年少时那份因为单纯的喜欢便放肆去追的快乐，似乎再也找不到了。<br /><br />=========================<br /><br />　　作为一位热爱编程的程序员，我一直渴望能够有那么一个机会，让我可以不必为了自己的饭碗而编码，可以不必为了“开发出足以改变世界的软件”这样伟大得难以承受的理想而编码。编码，只是因为我喜欢。<br /><br />　　《灌篮高手》里最感动我的一句话就是三井的那句:“我想打篮球”，是的，他打篮球可以不是为了妹子，不是为了进入NBA，不是因为自己是个天才，而只是因为最单纯的喜欢。那么我为什么不能如此呢？<br /><br />　　没办法，事实就是“我不能如此”。那些励志诗篇里读到的，那些励志歌曲里唱过的，似乎总是和这个世界格格不入。总是会有太多太多的事情，用最残忍的方式告诉我，不是每一场风雨之后,天空都会挂上彩虹;不是每一份骄傲的倔强,都能换来一次咸鱼的翻身。<br /><br />　　于是,虽然我一天天的长大了，头却一天天的低下了。好在内心对那个机会的渴望，从来没有停止过。当code jam活动出现在我眼前时，我知道，我等到它了。<br /><br />=========================<br /><br />　　我不知道参加这次广州深圳code jam的朋友，是否也和我一样有过类似的渴望，是否也和我一样因为纷扰的生活而冰封了自己的梦想，如果答案都是肯定的，那么我真的希望这次的code jam可以让大家的渴望得到一点小小的满足，让冰封的梦想看到某种融化的可能。<br /><br />　　虽然我不是code jam活动的发起者和组织者，甚至都算不上积极的参与者（只参与过3次，其中还有一次是纯酱油），但每次活动我还是无比的忐忑，我害怕活动会让参加的人感到失望，害怕HTML5研究小组辜负了大家的热情。降低忐忑的方式，便是降低期望。于是每次我都不敢把活动设想得太完美，不过好在每一次的活动，都证明我之前的担心是多余的。这次也不例外。<br /><br />　　刚到深圳那天晚上，也就是活动的前夜，和林挺走在路上闲聊。我说，报名的70人，实际能来40多就应该很好了。但是林挺显然对40这个数字不满足。他说，这毕竟是两个城市联合搞活动，还是希望人多点，太少了说出去也不好听啊。虽然他说的也有道理，但是我还是对人数不敢有太多的期望。<br /><br />　　第二天早上8点多，娜姐和我正走在去会场的路上，广州的余浩打来了电话，告知我们广州那边的30多人已经整装待发了，而且里面还有一位孕妇。这消息实在太让人振奋了,娜姐当场就忍不住来了句：“ X！（此处必须果断的 哔 掉）广州那边的同学太给力了”，她居然激动得说了个脏字（好吧，我承认“居然”两个字我加得有些多余，她常说脏话的）。<br />广州同学给力，东道主深圳的同学自然也不会落后了，我到会场时,已经有很多同学提前赶到,大家都跃跃欲试。9点多,人都到齐了，来了60多名选手,加上工作人员,共70多人，把中青宝最大的会议室挤得满满当当。这架势是前几次code jam所没有的，让我这个不是初次参加的人，也有一些紧张和激动，找到了第一次的感觉（浮想联翩 again）。<br /><br />　　经过激烈的创意PK，最后选出了13个策划（10款游戏+3款应用）。而我非常幸运的和两位策划组队，一位是充满激情的付敏同学，他在介绍自己的策划时，可是一下跃到了椅子上。另一位则是我前面提到的远道而来的孕妇，殷婉君同学。两位策划，一位程序，没有美术设计，这个组合很奇怪，不过我们仍然充满干劲的开始了code jam之旅。后来在五位其他团队美术设计师的帮助下，我们也完成了自己的作品。虽然不是很好，但是我们仍然很享受整个过程。<br /><br />　　除了自己团队埋头冲刺，去其他团队里“探班”一向都是code jam活动里必不可少的节目。这也是不可错过的增进友情、爱情和基情的好机会。更重要的是,每当我累了倦了，想偷懒了，去其他仍在奋战的团队里转一圈，便总能重获动力。而每个团队那些鲜活的人物，更是构成了code jam上一抹别样的风情。<br />　　站立办公、累了就喝两罐啤酒的老赵，盘腿而坐进入梦境的神人，为支持多个项目而来回奔波的设计师（有妹子），喜欢画同人热爱动漫的萌妹子（是妹子），彪悍的女程序员（还是妹子），来给老婆（又是妹子）助阵的好老公，用一夜的不眠换来了无限好运的天然呆（仍然是妹子）……还有好多好多值得一书的人（还有好多妹子），我就不赘述了，毕竟记叙文不是我擅长，但是有一个人还是不得不提起一下，雷锋一样的抒寒同学，他为了赶回公司加班，而和已经到手的ipad擦肩而过，当他中了奖却因为早退而被剥夺资格时，现场爆发出了一阵阵充满了惋惜的掌声=,.=，博得的掌声之热烈，远超优胜者，可见大家是多么的有同情心啊。 <br />　　看看前面括号里的内容，大家应该也不难看出这次活动的另一个亮点：好！多！妹！子！<br /><br />=========================<br /><br />　　这次code jam上，我虽然顶着嘉宾的名号，但实际上我并没有做什么特别的，我只是所有参加活动的60多位朋友中的普通一员，我很满足于自己的角色。一直特别喜欢腾讯微博曾经的一句宣传语：与其在别处仰望，不如在这里并肩。我真心希望以后还可以有机会和这样一群激情满溢活力四射的朋友再次并肩。并肩，不是为了多么崇高伟大的理想，只是为了让那些灵光一线的火花，可以变成看得见的光亮。梦即使渺小，只要实现了，就要对自己说一声伟大———此刻，我好想和大家一起再伟大一次。<br /><br /><br />　　虽然每次code jam，我们总是强调“作品好坏不重要， 重要的是大家在合作的过程中碰撞出的激情与火花，过程大于结果……”。但是我必须承认，这次的code jam活动，是HTML5 研究小组历次同类活动里平均水平最高的一次了。code jam给大家提供一个舞台，而大家却用自己华美的舞步，让这个原本简陋的舞台蓬荜生辉。娜姐，作为HTML5研究小组的创始人，你要怎么感谢大家，你看着办吧。<br /><br />　　当然，世上没有所谓完美，每次活动都会有一些遗憾，也都会有一些朋友玩得不开心，尤其是那些带着自己的想法来，最后却落选的策划人，只能有几分无奈的去帮忙成全别人的梦想。说实话，我曾经也想不通，总觉得自己的策划不错，凭什么我就要放弃啊。其实回过头来仔细想想，这也许是活动的另一个意义之所在：这次你成就了他人，那么下次当你有机会实现自己梦想时，你才会更懂得如何跟帮助你造梦的人相处与合作，才能更懂得尊重和妥协在团队里的意义，反之亦然。所以，活动上没有所谓的winner和loser，有的只是不停变换的角色，亦如人生，有时我们没得选择，但接受现状不等于失败，而是对未来的一种积累和沉淀。<br /><br />=========================<br /><br /><br />　　和素昧平生的人，从陌生到熟悉，一起实现一个共同的目标，让在这两天一夜里遇到的那些有趣的人和有趣的事，来丰满我们的人生和回忆——我一直觉得这才是code jam活动的真谛——然而，更重要的是，无论是在code jam的舞台上，还是在自己的人生旅程中，每当我们有了一个想法，一定要努力的抓住它，然后，拉上一群志同道合的朋友，去试着把想法变成现实，不要迟疑，不要等待，不要奢求还有下一次的机会，因为——有些事现在不做，一辈子都不会做了。<br /><br /><br /><br /></span>
              
              <br/><br/>
              <span style="color:red;">
                <a href="http://fins.iteye.com/blog/1465405#comments" style="color:red;">已有 <strong>2</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
              </span>
              <br/><br/><br/>
<span style="color:#E28822;">ITeye推荐</span>
<br/>
<ul><li><a href='/clicks/433' target='_blank'><span style="color:red;font-weight:bold;">—软件人才免语言低担保 赴美带薪读研！— </span></a></li></ul>
<br/><br/><br/>
              ]]>
            </description>
            <pubDate>Tue, 27 Mar 2012 20:49:54 +0800</pubDate>
            <link>http://fins.iteye.com/blog/1465405</link>
            <guid isPermaLink="false">http://fins.iteye.com/blog/1465405</guid>
          </item>
                  <item>
            <title>对 &lt;Opera(欧朋)H5浏览器移动版&gt; 的一些期许. </title>
            <description>
              <![CDATA[
              <span style="font-size: medium;">对 &lt;Opera(欧朋)H5浏览器移动版&gt; 的一些期许.<br /><br /><br />在前不久举行的#HTML5年会#上 ,有幸试用了 Opera(欧朋) 最新的一个移动平台浏览器 &lt;欧朋H5体验版&gt;.<br />虽然这只是一个体验版本, 还有很多的不足(甚至很多低级的bug),但是依然能够看到Opera剑走偏锋、不走寻常路的创新精神 以及以小博大的勇气.我相信 这款产品的特殊定位（专注HTML5， 提升WebApp和Web游戏体验）,会为它迎来属于自己的市场.<br />而且听说该<strong>H5版浏览器的核心开发团队在中国</strong>,于是对它又多了一分期待(也许我们中国开发者的诉求,能够被更多的重视).<br /><br />目前的版本还是体验版,而且由于一些低级的bug(例如经常非法关闭),导致我也没有太深入的试用,所以我写不出也没必要对测试中产品去写评测. 下面我只谈一谈我的一点期望吧.<br /><br />下面的很多期望可能Opera已经做到了，或者已经在roadmap里了,或者技术上根本无法实现, 那就当我没说好了.<br />毕竟我不是浏览器和NativeApp开发的专家，不专业之处大家一笑置之吧。<br /><br />========================<br /><br /><strong>1 加强Canvas性能, 支持硬件加速.</strong><br />	目前移动平台各个浏览器里,Canvas性能之王自然是IOS 5, 希望Opera也能达到甚至超过它.<br />	(android自带浏览器的canvas在处理Alpha通道时还会有一些莫名其妙的bug)<br /><br /><strong>2 支持离线应用</strong><br />	HTML5的游戏或WebApp如果没有离线应用,威力大打折扣啊.<br /><br /><strong>3 支持WebSocket</strong><br />	它的意义自然不必说.目前android内置浏览器还不支持, 这是一个机会啊.<br /><br /><strong>4 完美的支持多点触控</strong><br />	别说Android,就算是IOS 5的safari里的多点触控也存在着不足(多点频繁触控时 会出现事件丢失的bug)。<br />	希望Opera能实现最好的多点触控体验。<br /><br /><strong>5 支持重力感应(加速计)</strong><br />	重力（加速度）感应很有意义，很多应用和游戏会因此更精彩。<br />	至于陀螺仪倒不着急，毕竟用到的不多.而且宇宙第一神机小米手机都没有陀螺仪呢.<br />	<br /><strong>6 完善对声音的支持</strong><br />	移动平台的HTML5 Audio是老大难问题了,这个如果opera能解决的比较好 必然会赢得大量的赞许.<br /><br /><strong>7 加强对CSS3 3D的支持</strong><br />	比仅仅是支持,而且对3D部分一定要启用硬件加速. <br />	非3D方面, position=fixed 和 overflow=scroll 的需求太强烈了,不知道支持否.<br /><br /><strong>8 支持真正的全屏</strong><br />	目前浏览器里的全屏都是用 设置滚动隐藏的, 而且在Ios里 还无法隐藏系统状态栏,无法真正的全屏.<br />	希望Opera可以通过Meta或其他手段支持这一特性.(听说已经在开发中了)<br /><br /><strong>9 支持锁定屏幕的旋转</strong><br />	目前移动平台的浏览器,无法锁定旋转,除非在浏览器外部(系统级)锁定旋转,<br />	否则浏览器会根据机器的方向而在横版和竖版之间摇摆.破坏WebApp的用户体验.<br />	希望Opera可以让开发者甚至用户在实现页面级的旋转锁定功能.<br /><br /><strong>10 支持类似Ios的"加入主屏"功能,可以更方便的将网页的快捷方式加入手机桌面.</strong><br />	每次都让用户打开浏览器 再选择应用的方式还是有很多的不足 很多人也不习惯,希望能把页面链接到桌面.<br /><br /><strong>11 在Android上支持处理硬按键,就是机器上那4个(有的是3个了).</strong><br />	希望页面内也可以拦截到硬按键,例如 back和menu.(back目前可以通过迂回策略捕捉,但menu貌似还不能).<br /><br /><strong>12 对摄像头和麦克风的支持</strong><br /><br /><strong>13 其他</strong><br />在增加新功能时 尽量采用Meta和css等方式 避免提供过多的Opera浏览器专有API，以免应用失去跨平台特性。<br />没有提到WebWorker WebGL FileAPI XHR2等等 不是说不重要,只是我个人不太在意这几个特性.<br />当然 作为HTML5浏览器,那些该做的自然也要做好啊.<br /><br />最后, 快点出来吧.2012年chrome for android也要出了. 期待你们的碰撞.<br /><br /><br />=================<br /><br />以上都是我个人很直接的期望，我也知道里面有些期望可能根本就不能实现（例如 OS根本没提供相关的API, 或者是会违反Android/IOS开发协议,导致应用都无法上架), 但我还是提上来了,还麻烦Opera的工程师自行过滤吧.<br /><br /><br /><br /></span>
              
              <br/><br/>
              <span style="color:red;">
                <a href="http://fins.iteye.com/blog/1336132#comments" style="color:red;">已有 <strong>0</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
              </span>
              <br/><br/><br/>
<span style="color:#E28822;">ITeye推荐</span>
<br/>
<ul><li><a href='/clicks/433' target='_blank'><span style="color:red;font-weight:bold;">—软件人才免语言低担保 赴美带薪读研！— </span></a></li></ul>
<br/><br/><br/>
              ]]>
            </description>
            <pubDate>Thu, 05 Jan 2012 16:52:25 +0800</pubDate>
            <link>http://fins.iteye.com/blog/1336132</link>
            <guid isPermaLink="false">http://fins.iteye.com/blog/1336132</guid>
          </item>
                  <item>
            <title>小胖的&quot; MacOS常用免费软件 &quot;清单（有小更新）.</title>
            <description>
              <![CDATA[
              <span style="font-size: medium;"><br /><br />转眼用MacOS也有一年多了,　当初刚开始使用时,　网上很多类似"我的Mac软件清单"　"Mac必备软件"　一类的文章对我帮助很大.<br />最近换了Mac　Air　,正好有机会重新整理和审视一下自己机器里安装的软件.<br />在这里　把它们整理出来　希望可以帮助到和我一样的新人.<br />同时也欢迎大家提供更好的选择.<br /><br /><br />这列表里的所有软件　都是可以免费使用的,　不含有任何收费软件(有些是有收费版本的,但是免费版本也已经够用,否则我不会列进来).<br />当然　我不会装清高的说自己只用正版,　至少我机器里的　photoshop　和"office　for　Mac"就是最大的盗版.<br />但是　我一直本着一个原则:　如果不愿意花钱买付费正版,那么就尽可能的用免费的正版(freeware).<br /><br />另外这个列表里　只有软件名称　和　简单说明,　没有列出地址.<br />因为时间原因.　大家如果要找到他们　google　"软件名　＋　Mac　OS"　通常都可以找到,　记得　用google啊,　用百度的话找到流氓软件的概率你是知道的.<br /><br />好　开始正文吧<br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />系统工具　:<br /><br />QIM输入法 ： 我今天才知道它免费了，快试一试吧 真的很好啊。（我觉得可以代替FIT了）<br />Alfred ： 和Quicksivler类似的工具，但是持续更新，且用户体验做的很好，喜欢他胜过QS。<br /><br /><br />FIT输入法　:　qq和sogou输入法对一些软件(一些比较冷门,但是我要用啊)支持不好,最后还是坚持用FIT了.<br /><br />SL-NTFS :　打开MacOS的　NTFS读写功能.<br /><br />Perian　:　给QuickTIme提供更多解码包,让它可以播放更多格式.<br /><br />FlashPlayer　:　这个不说了<br /><br />AdobeAIR　:　很多不错的软件都是基于AIR开发的　装一个吧.<br /><br />KeyRemap4MacBook　:　Mac精简键盘的用户必备啊.　可实现对键盘上的按键进行重新映射,可让小键盘实现更多功能.　例如我就把右边的option键映射成了fn按键.这样我右手单手就可以实现很多以前要双手才能按到的快捷键了,例如fn＋delete＝del　(默认的delete是backspace,你也可以直接把delete映射成del).<br /><br />Go2Shell　:　为finder增加"在终端中打开当前文件夹"的功能<br /><br />FinderPath　:　这个也是finder增强工具,　让finder可以有地址栏,可以支持快速跳转等(快捷键操作,　其实包含Go2Shell的功能)<br /><br /><em>TrashMe :　引用＠流放之忆　的原话: "软件卸载工具。虽说Mac没有注册表，号称卸载程序直接删除就OK，但是还是会留下一些诸如配置文件、崩溃报告之类的垃圾文件。TrashMe就是为系统洁癖强迫症准备的。　　注意目前新版本进了App Store收费了，我用的是还未收费时的1.5.2版本，对我来说功能也够了。google下也能找到1.5.2的下载，"<br /></em><br />appcleaner : 完全可代替TrashMe,而且更强大.(之前用的老版本 觉得没有TrashMe好,现在新的已经很棒了, 也能查看具体删除了哪些文件.选择软件,点击search)<br /><br />OnyX and Deeper　:　Mac下的优化大师.有Lion版本了<br /><br />DesktopUtility :<br /><br />homebrew　:　包管理工具,　相当于mac下的apt了.　<br /><br />iSSH :<br /><br />CClean for Mac :<br /><br />Monolingual :<br /><br /><br />xld<br /><br />PropEdit<br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />媒体播放 : <br /><br /><br />MPlayerX : Mac下的必备播放器, 有人说VLC才是王道,　但是VLC我也装了,但却从来都懒得用.<br /><br />vox : 轻便小巧的音乐播放器, 不希望每次听歌都开itunes的朋友可以试一试<br /><br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />编辑器:<br /><br /><br />MacVim　:　虽然我不会用,但是不能少了它.<br /><br />TextWrangler　:　相当于Mac下的Editplus了,不过没有它好用.是BBEdit的阉割版,很多时候拿来用也ok.<br /><br />Bean　:　比系统自带的文本编辑器好用些,用来写RTF文档不错.<br /><br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />聊天工具:<br /><br /><br />QQ　:　人类已经无法阻止腾讯了.<br /><br />Adium　:　挂　MSN　GTALK　用它吧<br /><br />Aliwangwang　:　"这个还有货的.　满８０包邮哦,亲"<br /><br /><br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />下载工具:<br /><br /><br />迅雷 on Mac : 用着很不错.<br /><br />uTorrent　:　目前迅雷还不能完全代替它<br /><br />aMule　:　同上<br /><br />fileZilla　:　FTP/SFTP客户端.　虽然在Mac上界面丑了些,不过使用方式和windows上一样,用着习惯.<br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />阅读器:<br /><br /><br />iChm　:　看chm的工具<br /><br />Skim　:　看PDF的,　不过通常我只用系统自带的<br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />压缩解压缩:<br /><br /><br />The Unarchiver　:　平时常用它,喜欢它的简单.<br /><br />Keka　:　它的那个"去掉MacOS扩展资源文件"的功能吸引了我.<br /><br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />词典:　(对于我这种英语弱到爆的人, 自然是各种词典都要装了)<br /><br /><br />GDict　:&nbsp;&nbsp; 对google翻译的封装,体验蛮不错的.<br /><br />欧路词典 : 支持鼠标取词的词典<br /><br />金山词霸　: 老牌词典了,可惜mac版本好久不更新了.希望最近兴起的MacApp大潮下 它能持续更新啊<br />(我更期待有道词典Mac版)<br /><br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />图形图像:<br /><br /><br />xee : 看图软件,类似Acdsee 2.x 版本,比系统自带的还是强一点,可惜没有浏览模式.<br /><br />Captur : 截屏软件,虽然Mac自带的截屏已经很棒了,但是对手指要求有点高.<br /><br />Paintbrush : 一个简单的绘图工具, 但是比windows自带的画板要强出好多.<br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />脑图:<br /><br /><br />Xmind : Mac下的首选<br /><br />MindNode : 如果不常写脑图,只是偶尔用用,这个也不错,小巧很多.<br /><br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />虚拟机 : <br /><br /><br />VirtualBox<br /><br />wineskin ( wine on Mac 的工具包)<br /><br />Remote Desktop Connection　:　微软官方的远程桌面,连接windows系统的利器.<br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br />版本控制GUI工具:<br /><br /><br />Github for Mac　:　没啥好说的<br /><br />svnX　:　没啥好说的<br /><br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br /><br />最后,　如果你装了很多　软件,　又是个"软件更新控"怎么办?　装这个:<br /><br /><br />AppFresh　:　软件更新信息查询.查看你机器里的软件哪些有更新了(而且可以在这里统一更新).<br /><br /><br /><br />＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝<br /><br /><br />没了.　希望对大家有所帮助.　同时　希望大家也能帮助我一起完善这个列表　谢谢了.<br /><br /><br /><br /><br /><br /><br /><br /><br /></span>
              
              <br/><br/>
              <span style="color:red;">
                <a href="http://fins.iteye.com/blog/1171109#comments" style="color:red;">已有 <strong>6</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
              </span>
              <br/><br/><br/>
<span style="color:#E28822;">ITeye推荐</span>
<br/>
<ul><li><a href='/clicks/433' target='_blank'><span style="color:red;font-weight:bold;">—软件人才免语言低担保 赴美带薪读研！— </span></a></li></ul>
<br/><br/><br/>
              ]]>
            </description>
            <pubDate>Tue, 13 Sep 2011 18:16:08 +0800</pubDate>
            <link>http://fins.iteye.com/blog/1171109</link>
            <guid isPermaLink="false">http://fins.iteye.com/blog/1171109</guid>
          </item>
                  <item>
            <title>[已出]出售二手Macbook pro 374 ， 详见内文 （有文 有图 有视频）</title>
            <description>
              <![CDATA[
              <br /><span style="color: red;"><span style="font-size: large;">[已经成交了 , 但此贴决定继续保留, 作为以后网上卖东西的模板,哈哈]<br /></span></span><br /><br /><br /><br />因近日购入了 MacAir 11cun， 所以想把自己手里的macbook出了， 具体见下文。<br />(后有视频和照片链接)<br />谢谢了<br /><br />======================<br />机器基本信息：<br /><br />型号： MacBook Pro 13.3寸,&nbsp; 型号 MC374ZP/A&nbsp; (俗称 2010款MBP 374)<br /><br />关键配置:&nbsp; <br />屏幕:&nbsp; 13.3英寸,&nbsp; 最大分辨率 1280*800<br />CPU:&nbsp; Intel 酷睿2 双核 P8600 , 主频2.4GHz<br />内存:&nbsp; 4G DDR3<br />硬盘:&nbsp; 250G 5400转 SATA<br />显卡:&nbsp; NVIDIA Geforce 320M<br />自带系统:&nbsp; MacOS X 10.6.3&nbsp; 雪豹,&nbsp;&nbsp; 能够升级到最新的10.7 狮子。<br /><br />其他配置 如接口等 请网上自行上网搜索。<br /><br />======================<br />购入情况：<br /><br />2010年8月7号购买的 全新港行机器。<br />购入价 8250元人民币。<br /><br />含全新主机+ 官配 + 普通屏幕贴膜，普通内胆包，moshi键盘膜，moshi触控板膜 （这些配件目前都还在使用中）<br /><br />全球联保，但自带的一年保修已过。<br /><br />======================<br />使用情况：<br /><br />主要用于日常办公， Web开发（写写js html css）， 上网。<br />除出差 外出开会携带之外， 基本上都在家中充当台式机使用。<br /><br />电池写本文时充电循环32次。 目前电量上限5358mAh，设计上限是5770mAh。<br />对于使用一年的笔记本而言，电池状况非常良好。<br />我使用电池时至少能连续使用4个小时以上(我不玩游戏）。（机器刚入手时不行，不过后来随着电池逐步被激活，时间越来越长）<br /><br />使用期间，由于各种膜护体，机器本身保存完好。<br />机器的配件和外包装也保存完好，甚至连内部的塑料袋 防磨纸都还在。<br />(这是我的第一台苹果电脑,我还是很珍惜的啊)<br /><br />机器整体感觉还是蛮新的。但是至于几成新 我不敢说，因为每个人对几成新的定义不同。所以请自己看照片和视频来衡量吧。<br /><br />（详见照片和视频）<br /><br /><br />======================<br />维修和故障情况：<br /><br />机器本身从来没有过问题，也从未因任何原因进行过拆卸。 但是发生过两次小意外。<br /><br />1 电源适配器发生过充不进去电的情况。 <br />因不慎重摔适配器，导致适配器出现故障。<br />去浦东陆家嘴Apple店保修，更换了新的电源适配器后一切正常。<br /><br />2 去年冬天发生过触控板失灵的问题。<br />当时出差去北京， 在手部静电过大的情况下触控面板，导致触控板失灵。<br />后来发现 不是触控板的问题， 而是触控板贴膜好像被静电影响。<br />撕下贴膜 重新贴回去后 就好了。直到今天 什么问题都没有。<br /><br /><br />======================<br />目前已知瑕疵：<br /><br />1 屏幕贴膜有若干划痕，但不明显， 更换贴膜后应该没什么问题。<br /><br />2 由于前面提到的“故障2” 我撕下过触控板膜，所以如今触控板膜右下角有点翘起。不过不影响使用。 我这里还有一张全新的 moshi 触控板贴膜 如果需要 可自行选择更换。<br /><br />3 键盘膜基本上发黄变色的很厉害了， 建议更换。<br /><br />4 电源接口有磨损的痕迹， 这个正常，因为插拔电源行为。 电源接口后侧， 有一个划痕， 不知道什么原因。 （详见照片）<br /><br /><br />======================<br />出售情况：&nbsp; 5200 元。 (本来不想标价， 可有太多搞笑的）<br /><br />上海本地， 现金交易。<br /><br />之前网上搜索了一下 ，其他使用1年的mbp 374 ，4500 --- 5500 不等, 新旧程度各异。<br />也有人说， 数码产品这东西 入手就打对折，一年使用再打对折， 2000多撑死了。<br /><br />这个我不发表看法。大家自己决定吧。<br /><br />感兴趣的可 在这里 或 新浪微博联系我 <br /><br />微博：&nbsp; <a target="_blank" href="http://weibo.com/finscn">@大城小胖</a> <br /><br /><br />======================<br /><span style="font-size: large;"><span style="color: red;">提示:</span></span><br /><br />购买二手商品有风险, 购买需谨慎.<br />本人不提供 包修包换包退等售后服务.<br />现场验货完毕, 如决定购买, 一手钱一手货之后,一切听天由命.<br /><br />由于我在网上的信息还算公开 : 姓名 性别 工作单位 手机号码 照片等,很容易搜索到, <br />所以我也不可能卖一个垃圾给你, 这点大家还是可以放心的.<br /><br />不过 还是提醒您, 三思.<br /><br /><br />======================<br /><span style="color: red;"><span style="font-size: large;">好了 最后是视频和 照片 :</span></span><br /><br /><br />视频1 : 完整外包装+ 二手伪开箱视频.<br /><a target="_blank" href="http://v.youku.com/v_show/id_XMzAzNDc2NTEy.html">http://v.youku.com/v_show/id_XMzAzNDc2NTEy.html</a><br /><br />视频2 : 一些细节:<br /><a target="_blank" href="http://v.youku.com/v_show/id_XMzAzNDg2NzY0.html">http://v.youku.com/v_show/id_XMzAzNDg2NzY0.html</a><br /><br />照片共8张 , 去下面看 :<br /><a target="_blank" href="http://fins.iteye.com/blog/album_by_tag?tag=macbook">http://fins.iteye.com/blog/album_by_tag?tag=macbook</a><br /><br /><br /><br /><br /><br /><br /><br /><br />
              
              <br/><br/>
              <span style="color:red;">
                <a href="http://fins.iteye.com/blog/1170394#comments" style="color:red;">已有 <strong>0</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
              </span>
              <br/><br/><br/>
<span style="color:#E28822;">ITeye推荐</span>
<br/>
<ul><li><a href='/clicks/433' target='_blank'><span style="color:red;font-weight:bold;">—软件人才免语言低担保 赴美带薪读研！— </span></a></li></ul>
<br/><br/><br/>
              ]]>
            </description>
            <pubDate>Mon, 12 Sep 2011 17:26:22 +0800</pubDate>
            <link>http://fins.iteye.com/blog/1170394</link>
            <guid isPermaLink="false">http://fins.iteye.com/blog/1170394</guid>
          </item>
                  <item>
            <title>尝试挑战 running panda ， HTML5的跑酷类游戏（开发中）</title>
            <description>
              <![CDATA[
              我业余时间一直在尝试用HTML5 在ios平台上开发webgame （ios是所有移动平台里对HTML5支持最好的，同时又不支持浏览器中的flash，所以我相对偏重于HTML5在ios中的应用）<br /><br />如今 flash通过某种方式 也可以跑在了ios中， 也涌现出了一些不错的游戏。<br />其中running panda是非常不错的一款。<br />为了便于对比，我打算用HTML5技术在ios上开发一款类似running panda的游戏<br />目前刚刚开始 ，还在开发中。<br />HTML5跑酷类游戏原型测试地址 : <a target="_blank" href="http://t.cn/aYL3Eo">http://t.cn/aYL3Eo</a><br />（点击屏幕让人物跳跃。）<br />欢迎使用装有 iso 4.2 或以上版本的 itouch 或 iphone 访问 (不支持mac、pc)。<br /><br />目前这个还不是一个游戏， 只是一个简单的测试场景。<br />不过根据现在的表现来看&nbsp; HTML5在 itouch4、ip4上还是能够胜任这种类型的游戏的。<br /><br />希望大家能够关注这个游戏， 关注HTML5的发展。<br />这个游戏的最新情况，我会在微薄上更新(新浪微博 @大城小胖)&nbsp; 欢迎关注.
              
              <br/><br/>
              <span style="color:red;">
                <a href="http://fins.iteye.com/blog/1136943#comments" style="color:red;">已有 <strong>4</strong> 人发表留言，猛击-&gt;&gt;<strong>这里</strong>&lt;&lt;-参与讨论</a>
              </span>
              <br/><br/><br/>
<span style="color:#E28822;">ITeye推荐</span>
<br/>
<ul><li><a href='/clicks/433' target='_blank'><span style="color:red;font-weight:bold;">—软件人才免语言低担保 赴美带薪读研！— </span></a></li></ul>
<br/><br/><br/>
              ]]>
            </description>
            <pubDate>Mon, 01 Aug 2011 00:02:53 +0800</pubDate>
            <link>http://fins.iteye.com/blog/1136943</link>
            <guid isPermaLink="false">http://fins.iteye.com/blog/1136943</guid>
          </item>
          </channel>
</rss>
