V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  sillydaddy  ›  全部回复第 1 页 / 共 95 页
回复总数  1887
1  2  3  4  5  6  7  8  9  10 ... 95  
1 天前
回复了 24 创建的主题 V2EX V2EX 新账号注册机制
站长应该都门儿清。新用户注册数量、每月发帖数量、活跃账号数量,......,这些数据站长都有的。发现趋势不对,应该会改吧。
我理解的对不对:用户手持人民币,但商户只收 usdt ,于是出来个中间商,把人民币换成 usdt ?
这在禁止加密货币的地方,明显是不符合政策的。
另外匿名也说不上吧,按你说的,用户需要到商户提供的网站验证券是否未被使用,这一步商户就无法匿名了吧,商户作为公司实体,需要提供实体的注册信息吧。
同楼上问,这缺额工作量是怎么算的?按理说,额定工作量应该是按照 8 小时工作制来计算的吧。
这是天性改不了的:不忍铁锈着,磨剑不敢歇。
12 天前
回复了 Karte 创建的主题 程序员 前端真的可以这么水吗?
我通过“嵌入式 奇技淫巧 sillydaddy” 搜索到了 v 友面试遇到的一个题目给楼主看能不能做出来:

“请用一个 C 语言表达式判断某个数是否为 2 的 N 次幂 ”
12 天前
回复了 codigger 创建的主题 程序员 程序员与编程领域,似乎符合 10x 定律
今天又去查了下 10 倍定律,发现跟 OP 描述的含义不同。正确描述应该类似 3 个 16 定律:
16 次做同一件事,每次比前一次少花 16%的时间,那么第 16 次做时只需要花费最初 1/16 的时间。

上面的表述才是 10 倍定律的真正含义:想比原来效率高 10 倍,至少要花 10 倍的努力。这 10 倍的努力可以是通过重复做 10 次每次都有新的理解,也可以通过第一次就耗费大量的额外的 10 倍精力去把事情做透彻而不仅仅是做完而已。
12 天前
回复了 codigger 创建的主题 程序员 程序员与编程领域,似乎符合 10x 定律
我不认同你的观点。第二次实现跟第一次相同的功能,如果不是通过拷贝第一次的代码的话,并不会快多少。我写过自己并不熟悉的 python 爬虫、javascript 前端,配置过前端的编译链 gulp ,现在让我从头写,我还是会像第一次一样抓狂。所以你的 10x 理论只是臆想。
写的太乱。给你看一个竞品:
/t/985173
12 天前
回复了 Jyuagd 创建的主题 软件 求一款 mac 端软件,忘记叫什么名字了
这个描述感觉很熟悉。搜一下 Image to vector 呢,或者“像素矢量化”,“图片矢量化”。
13 天前
回复了 zxlBen 创建的主题 职场话题 如果看待公司强制分配绩效等级名额
绩效应该有一个固定的基准,只要比这个基准高就可以。工资高基准就高一些,工资低就低一点。比如参考市场上的平均水平。
强制摊派低绩效就是胡搞,内卷没有止境。
14 天前
回复了 young1 创建的主题 程序员 设计模式
如果你仔细观察那么多设计模式,会发现它们基本上都是在讲一件事:接口的抽象、分层、去耦合, 就像 #26 楼 @NoOneNoBody 说的。把这点仔细研究研究,就豁然开朗了。

举几个例子,

「观察者模式」: 某个对象变动了,通知其他对象(或者说其他对象观察某个对象的变动)。 这种“一变动就通知”的机制,主要用于底层对象向上层对象发送通知,对于这些通知,无论上层对象是处理还是不处理,无论上层具体怎样处理,都跟底层对象没有关系了。所以观察者模式,其实是将底层对象的向上通知这种(接口)行为统一抽象出来了,而且去掉了底层与上层的耦合。
「访问者模式」:将被访问的数据结构的遍历抽象出来了,上层要访问某个比较固定的数据结构的时候,不用每个访问者把遍历这个数据结构的代码都重复写一遍,只需要写出来对该数据结构如何具体操作,遍历这个数据结构的过程已经被“访问者模式”抽象和剥离出来了。像 C++ stl 的迭代器也可以算是非常典型的访问者模式,只需要 iterator++就可以,不用关心底层是 vector 还是 list 。
「工厂模式」:这个就更直接了,传给工厂一个不同的参数,生成一个与之对应的实例,并且这些实例都实现了一个相同的接口。具体生产哪个类的实例不需要关心,唯一需要关心的就是,传入一个不同的参数,得到同一个接口的不同实现,经过这种抽象后,工厂模式对外呈现出一种极为简洁的形式:不同参数->接口的不同实现。


所以学习的时候,只要仔细留心接口是怎样抽象的,接口抽象出来后,达到了什么目的和效果,就可以了,不用特意记各种设计模式,死记也记不住。
@meeop 前面提到的周转资金,可以从另一个角度考虑:
如果一个商家,每天卖出 100 件商品,商品总成本 10000 元,第 2 天可以收到付款。这个商家的库存里面,总是保留用于第 2 天卖的,与第一天卖的 100 件一模一样的商品。也就是说这个卖家只需要投入 20000 元,就可以维持它的生意不断,它库存与销售比是 2:1 。
如果使用押金模式,那么它需要 10000*10+10000=110000 元才能维持,也就是资金利用率只有原来的 1/5 左右。
如果扩大商家的库存销售比,比如扩大到 10:1 ,资金利用率也只有 1/2 。
所以这种高押金模式,对于商家/工厂来说,资金利用率是很低的。如果它的资金中有 50%是贷款,贷款利率是 4%,原本它的 6%的利润率就足够,如果它的资金利用率只有一半,那么它的利润率就要提升一大截才行。
@meeop 我想到了一个可能的问题。
如果双方的目的是交易,那么感觉这个方案非常合适。
但是,如果其中有一方的目的不是交易,而是借助这个机制进行攻击呢?
下面介绍这种通过耗尽对方资金进行的攻击方法,我把它叫做“榨汁攻击”:
如果有一方是专门通过出售商品获利的,那么它所拥有的资金一般总是充分利用的,甚至有些资金还是通过借贷获得的。也就是说,它的资金几乎全部用于商品的周转。这时,如果有大体量资金的对手针对它发起大量交易并拖延交易的达成,那么只需要十分之一的交易量就能耗尽它的资金。一方资金耗尽的话,就完全失去了继续盈利的能力,也就丧失了谈判的筹码。
对于闲鱼二手交易,如果某个专职卖家中的买方中有二十分之一的人采用榨汁攻击,那么会导致占用该卖家的 50%的周转资金。而这些资金很可能只占用买家的很小一部分。这种明显的优势可能会促使买家结盟,构成所谓的 DDOS 攻击。
1  2  3  4  5  6  7  8  9  10 ... 95  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5181 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 48ms · UTC 09:28 · PVG 17:28 · LAX 01:28 · JFK 04:28
Developed with CodeLauncher
♥ Do have faith in what you're doing.