V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Quaintjade  ›  全部回复第 26 页 / 共 153 页
回复总数  3052
1 ... 22  23  24  25  26  27  28  29  30  31 ... 153  
@jarlyyn
显然是服务的过程开始于 APP 内。知乎文章发在知乎上时服务尚未开始,开始时间是用户用知乎 APP 打开这篇文章开始阅读,结束于读完文章。同理,微信号文章的服务开始于用户打开微信文章,只是微信连同后面的服务一并做了罢了。
你用 safari 看文章然后打赏又不会抽成。

至于为什么是服务,我倒要问你为什么不是服务?如果不是服务那么作者为了什么写文章?微信为什么要为作者创建这个平台和功能?你为了什么打赏?如果只是转账,为什么打赏按钮要放在文章末,而且打赏的对象是文章作者?
记得有个段子说卖淫嫖娼可以解释成“两人通过宣传单认识对方并一见钟情,然后一夜风雨过后发现不适合于是就分手了,感觉过意不去于是就补偿了点分手费”。以常识就能知道行为的真实目的,没必要强行解释一波。
2017-06-27 13:13:11 +08:00
回复了 ZRS 创建的主题 Apple 可能是我有生以来见过最智障的 bug
第一次在 WP 上登录微信也遇到过类似设计,选出你的朋友验证的确认按钮被底部虚拟控制键挡住按不到。
后来才知道 WP 的虚拟键可以隐藏,方法是有点反直觉的边缘向上滑动。
@mooncakejs
如果你愿意把它理解为交税的话,那么就更容易类比了。
应该说这更像流转税(例如营业税或增值税),而不是所得税。流转税的特征是基于消费金额多少征收,而不是基于收入多少征收,哪怕你是亏钱的,一样得支付流转税。

除了少数特定行业,流转税都是对消费金额全额征收的,哪怕只是转手倒卖。而那些特定行业差额征收,默认前提是上游自己也会缴纳流转税。
苹果则无法单独对上游供应者(写文章的公众号)“征税”,所以只对增值部分“征税”就不妥当了。

假如换成所得税的话,那么连应用内的广告收入、合作赞助收入等都要被苹果抽成了。
@mooncakejs
事实上这牵涉到比较底层的问题:

1.微信余额:入账时并不区分用于 APP 内消费还是 APP 外,而出账既能用于微信 APP 内的消费项目(本应该走 IAP 被抽成),也能用于 APP 外消费项目或非消费项目(不走 IAP,不抽成)。假如能区分的话(像手游购买点卡),一般在购买余额时就走 IAP 了。
婚礼转礼金一般属于后者,毕竟你支付礼金不是因为对方请柬做得多精致。而公众号打赏则是因为读了 APP 内提供的文章,觉得文章本身写得好。

2.微信绑定快捷支付:本质上是银行卡支付到对方账户。如果对方是微信 APP 外的商家,那么和淘宝购物类似;如果对方是微信 APP 内内容提供者,那么和 APP 内消费差不多,理论上应该走 IAP ;如果对方是一般用户,那么属于为对方的微信余额充值,回到了上面微信余额的问题。注意应用内捐赠是不允许的。
@BXIA
我指的是京东自己的 APP 里卖京东的 Plus 会员,虽然部分权益可能延伸到线下。
至于微信内购买京东 Plus 会员,这个的问题不在于微信这头,而在于京东那头。如果京东 Plus 能在京东 iOS APP 享受权益,那么不应该通过第三方支付而应该走 IAP。

微信公众号的文章完全就是在微信 APP 内阅读的,完全满足在应用内消费。
@jarlyyn
打赏是消费。事实上 Google 也是这么认为的:
https://www.reddit.com/r/androiddev/comments/2vsyq4/beware_google_bans_app_from_playstore_because_of/

而且如果不是消费那是什么呢?捐赠吗?
别忘了苹果本来就不允许在应用内捐赠,那下架就更合理了。
@jarlyyn
关于为什么微信内文章打赏构成应用内服务前些日子早就讨论烂了。
条件是“消费行为在应用内发生”,和发布者在哪里写东西没有关系,你举的“手机充值”也不恰当。硬要说的话,也就京东在 APP 内购买 Plus 会员可以构成应用内消费。
@MC
交通卡有两种发票,一种是充值发票,另一种是乘车后的发票,例如出租车机打发票、地铁站服务台索取的定额发票。严格来说只有后一种才能报销。

商家预售购物卡会计上并不构成销售,购买者会计上也不构成消费。无论买方卖方都要等到实际购物时,账面上才能做费用 /收入。
之所以买卡时就开票,只是税务上出于实务考虑。对于税务局来说更方便管理(有现金转移易于监查),对商家来说反正已经收到钱了,又只能在自家消费,开票就开票好了。

关于预售卡税务上的规定,参见国税总局公告 2016 年第 53 号:
http://www.chinatax.gov.cn/n810219/n810744/n2048831/n2059355/c2254755/content.html
@ryd994
这在企业中有什么应用例子吗?
看各种报道好像都在强调区块链保障记录的真实性可信度,感觉有些迷。
@jigloo
我觉着说不定这根本就是证书体系,只是赶时髦用了区块链的名义……
@jigloo
好像有点道理。虽然我能想到通过抽查来发现没报告给总部的证书,或者下游把上游的证书汇报给总部,但这的确增加了日常审计成本。
问题是区块链又如何解决这个问题呢?各部门也能偷偷搞个私钥来签吧,最终还是被查到时才会发现。

@h4x3rotab
Certificate transparency,简单来说就是所有 CA 签了什么证书都要公开。没有 CT 的时候,像沃通假如偷偷签个 google.com 证书给 ZF,别人是不知道的。
@jigloo
既然是整个企业内部的证书体系,推行 CT 应该更容易吧?所有下级机构签发了什么证书都要汇报给总部。
甚至可以要求每一次用证书签发文档,上下游都要向总部汇报记录。
2017-06-25 14:40:59 +08:00
回复了 lcqtdwj 创建的主题 问与答 比特币去中心化是否是伪命题?
另外就是存储硬件很久没降价了,闪存甚至还大幅涨价。
2017-06-25 14:38:47 +08:00
回复了 lcqtdwj 创建的主题 问与答 比特币去中心化是否是伪命题?
比特币前段时间达成过共识,好像是在六个月内完成扩容,这样交易速度会大幅上升。

比特币大部分初始设计是可以升级修改的,但由于矿场矿池已经逐渐中心化了,导致矿工与币主之间的阶级博弈,很多改革难以推进。
除了上面勉强达成的扩容(会降低手续费收益率),再比如“算法更换成面向显卡的算法”这种提议显然也会遭到所有矿工的反对,因为矿工们都在用 ASIC。
2017-06-24 15:27:34 +08:00
回复了 1oNflow 创建的主题 程序员 回复邮件的标题该怎么写?要不要附带每次对话原文?
至于附带对话全文我觉得是必要的,如果太冗长的话就手动删掉。有时你需要把整个对话转发给第三人,如果不附带全文的话会变得莫名其妙。
没必要的是缩进,因为回复 N 次之后就没法看了,尤其是不仅缩进还按字符数强制换行的( iPhone,说的就是你!)
2017-06-24 15:20:51 +08:00
回复了 1oNflow 创建的主题 程序员 回复邮件的标题该怎么写?要不要附带每次对话原文?
只加一个 RE:就行。
最烦见到的是 RE: 答复:RE: 答复:RE: 答复:…… RE: 主题 ,不仅标题长,还会导致分割成 N 个会话( QQ 邮箱,说的就是你!)

借帖问一下,邮件如何识别若干封邮件是同一会话的? Outlook 似乎手动改一点标题就会打断成另一个会话,但修改内容并不会打断,完全相同的标题也不会识别成同一个会话。
2017-06-24 14:59:22 +08:00
回复了 a554340466 创建的主题 程序员 自搭网盘有什么好方案吗
如果只是因为限速的话,自用还是花钱买百度 SVIP 了,一般来说成本比用 VPS 自建网盘低。
自建网盘主要是为了分享容易被 8 秒的资源,或者团队协作。
2017-06-20 16:24:57 +08:00
回复了 xu33 创建的主题 程序员 前端不往全栈发展就要失业了吧
我觉得前端最难的是找轮子。小东西做做半天一天的事,找轮子、了解轮子、挑选轮子倒是要花几天。
而且过段时间发现又有新的轮子了。
2017-06-19 17:56:15 +08:00
回复了 superpeaser 创建的主题 问与答 今年的 618 是来搞笑的吗,想买的不降反升
许多商品是先涨价 80%-90%,然后满 199-100 之类,如果够量的话会比天猫淘宝便宜。
满减、优惠券、预约、买 X 送 X 套路太多挺累的。

现在 618 和双 11 都一样,去年双十一也一样耍猴,真优惠的商家商品总是少数。
1 ... 22  23  24  25  26  27  28  29  30  31 ... 153  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1032 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 29ms · UTC 19:49 · PVG 03:49 · LAX 11:49 · JFK 14:49
Developed with CodeLauncher
♥ Do have faith in what you're doing.