首页   注册   登录
 FrankHB 最近的时间轴更新

FrankHB

V2EX 第 34994 号会员,加入于 2013-02-28 10:06:28 +08:00
FrankHB 最近回复了
@noobcoder1 Review 不清楚的后果自负。说好的不听还能干啥?打得过有主线 force push 权限有本地访问权限的配置管理员?不想自己维护的计算工作量的分支整个历史被编辑掉就老实听话,哪来那么多事儿。
你似乎没搞清楚,一般情况下,所有 remote 上所有(不是以团队成员命名的)公开的 feature branch 的工作是有需要就要准备移交的,从来就不可能完全是“自己的”分支,这样的分支上历史出偏差是要负责任的。而真正所谓“自己”的分支,要么是提前约好的专用分支,要么干脆是不 push 都随便的本地分支(当然,不算在工作量里),本来想怎么搞就怎么搞。
还有,你的“最新的代码合到自己分支上继续开发”“尽早解决冲突”的做法根本没法保证“冲突应该会很少”;即便冲突真的不多,历史也可能因为到处非 ff 的 merge 整个乱了。
原则:只要是往上 push 的东西,就应该清楚这些工作会影响到别人的 base。对应地,自己到底依赖的是什么 base 分支也必须清楚(这不只是管理的要求,不守规矩可能自己这边重现 bug 都可能呵呵),而且除非你自己保证负责 squash 掉,否则就不应该无脑尽早解决——要是你依赖的 base 更新了再回退,难道你这里还非得多 merge 几次才更好看?搞清楚你的历史 merge 后也会进被合的分支里。不要搞得 push 完到处意义不明的 merge,让别人看不下去再替你 rebase 浪费时间。
1 天前
回复了 Bwoywan 创建的主题 微信 当代笑话 有人想教张小龙做产品
@vmebeh mpq 和下载后解压的更新包相比主要的差别是内容用私有格式加密和延迟解包。
如果每次加载时解包,可能影响加载体验,实现逻辑上也未必有更新时解包容易。
如果旧版本很多内容应该能被新版本覆盖掉,直接增量更新也会浪费空间。

根本上,下载压缩的更新包和小文件各种有优缺点。关键是看给谁省事。

对服务端来说,相对直接更新小文件,一整个更新包能提供以下优势:
1.节约更新服务器存储、带宽和请求压力。
一整个更新包压缩起来通常更小,文件数也显然更少。
2.提升更新服务器自身更新和同步时的可靠性。
减少收拾更新了一半出故障的烂摊子的成本。
3.实现简单,算法可按需灵活更换。
4.更新包作为事务边界,简单地保证客户端更新的完整性。
可整体加校验,比校验小文件方便得多。
5.更新包方便续传。
考虑更新可能覆盖文件,要保证准确覆盖对的状态不容易维护,可能还需要约定写入顺序。
不分块,下载一半掉线,默认已下载写入的部分可靠,不用重新请求已经下载的部分,接着往后下载就行。

直接下载文件相比先下载再解压更新的主要好处是可以并行下载和安装。不过,大部分不太大的更新上这个优势不明显。(又不是 Visual Studio ……)
其它的小的实现上的差别……除了可能省点时间(考虑压缩小文件传输可能更节约时间,实际不一定),基本上就是给客户端省了点电,但逻辑实现和服务端的开销还是没省。
2 天前
回复了 Bwoywan 创建的主题 微信 当代笑话 有人想教张小龙做产品
@zushi000 我说的是考虑项目管理的涉众为主的一个侧面角度,你说的是垂直领域的另一个侧面的一些角度。评价这些成功并不矛盾。我也基本上同意你说的对待产品的态度的问题。不过这里我更在意的是微信有这个底气的更根本原因。
微信为什么用户多?
我想,很大程度是赶上了移动互联网的车,而提供了大量之前对 IM 功能不敏感的非核心用户。
也正是如此,多数用户理解的“成功”恐怕比你我说得简单得多:到处都在用且有很多人用。
具体来讲,很多中老年人根本不用电脑(也不用手机 QQ ),这些基本就没什么产品预期的用户自然容易被先入为主地洗脑。至少相对短信这样的形式,微信确实提供了更多实惠的功能,所以他们眼里这就算是个成功的产品了。然后,这些人虽然个体表达能力不强,但凭借数量和家庭和社会地位的绝对优势集体垄断了用户之中的话语权,加上各种垂直领域的新功能的实用化(特别是金融和生活服务相关的),相对更理性了解微信 IM 功能缺陷的用户的声音被淹没了。这样,凭借话语权垄断,微信歪曲了它作为产品“成功”的内涵。
我算不上微信的核心用户,因为很早就被各种莫名其妙的设计恶心到了而避免主动使用(基本就是只有应付长辈的时候用;其它情形下 IM 功能最不济也有 QQ 顶着),也因此我并没怎么接触张小龙团队,不清楚应付产品反馈上的态度露骨程度。考虑到微信的功能不少有其它选项而不至于像用户话语权一般垄断,我也没热心去怼(而只是乐意落井下石)。但是,不了解同类产品而盲目支持微信的用户群体和基数还是摆在那里。只要有这个前提在,根本上很难保证没有一个被骂成狗的张小龙第二。那么剩下的一个问题,如果不幸再有类似的情况,作为少数群体的用户该如何应对?(七大姑八大嫂要加微信还不能不给面子就够烦的了……)
2 天前
回复了 Bwoywan 创建的主题 微信 当代笑话 有人想教张小龙做产品
@zushi000 成功有很多不同的角度。
项目方和投资人这样的核心涉众自己是怎么想的?满足了多少既定目标?外人大概只能靠猜了,实在有很多变数。虽然就他们的立场上整体上算成功看上去没问题,但至少成功的程度也不是一概而论的。考虑项目本身,像用户数和变现的能力算是项目自身的商业成功,但现在这样的用户体验混乱的问题真的就是计算之内的吗?还是把原来的目标妥协打折的结果?再考虑项目外的影响:这个市场格局是项目方预料好的吗?特别地,虽然鹅厂有内讧不奇怪,但是好歹资方最终利益应该是一致的。在已经有 QQ 的情况下出来一个微信和 QQ 竞争这个风险是不是值?在微信立项的当时这就不是显然的。现在两边问题都不很大,这个意义也是能叫成功;要是大水冲了龙王庙,那即便微信能达到现在的影响,也不会被当作现在这样成功。
对用户来说,他们享受到本来就应该容易得到的更好的服务、更有效地满足需求了吗?这个就不是那么难想了。对瞎下载东西把机器弄卡的问题,用户很多也是很有意见的。然而,作为主力的中老年人表达不满意的平均能力较弱,这些用户的不满被严重低估了。算上这些因素,还算很成功吗?
而就整个 IM 发展的历史来讲,通过跟现在的类似产品对比就能发现微信在很多地方开了倒○车,就更难以称得上有多成功了。
2 天前
回复了 Bwoywan 创建的主题 微信 当代笑话 有人想教张小龙做产品
@vmebeh 下载完再解包很正常,否则出现几 w 小文件下载 99%失败这类情况就呵呵了(不管是扔掉进度全部重下还是头铁同步状态都容易被用户打)。不过正常更完就该把包删掉。
2 天前
回复了 Bwoywan 创建的主题 微信 当代笑话 有人想教张小龙做产品
@zppass 不巧,因为恰巧有个 QQ,比竞品差的一些地方就露马脚了。
光是这些部分就明显就不是“差不多”。
@zushi000 有个问题,什么算成功?
要是背靠腾讯是主要原因,QQ 算不算更成功?
如果要拿用户基数来衡量成功,大概“天时地利人和”——数量最多的这届用户恰好比较白目——才是“成功”更重要的原因。
另一个问题,微信这个项目的具体目标,外人都没法明确,如何能否定?
看来这里很多人自始至终都没理解,名义上吐槽产品问题,其实真正是给谁看的呢。
2 天前
回复了 Bwoywan 创建的主题 微信 当代笑话 有人想教张小龙做产品
@cmdOptionKana 这玩意儿被怼显然不只是因为作为工具的问题。
至少正常来说,你不去用的工具不应该会上门来烦你,然而借助社交网络传播的瘟疫就是另一回事了。
2 天前
回复了 Bwoywan 创建的主题 微信 当代笑话 有人想教张小龙做产品
@Messiv2 都有罪也行啊,看创造价值折抵多少罪行好了,又不表示谁都不相欠了。不愿意体现自己创造价值的剩下罪多的欠罪少的,因为揩油被鄙视,有不公平么。
(跑个题,996 多少同理。)
3 天前
回复了 Bwoywan 创建的主题 微信 当代笑话 有人想教张小龙做产品
苏联(?)笑话:张小龙做过当代产品,,,
@tozp ……GateHub 吃 KYC 账户动不了求破。。。
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2219 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 12ms · UTC 14:39 · PVG 22:39 · LAX 07:39 · JFK 10:39
♥ Do have faith in what you're doing.