速度比 try 快很多哈
"%.2f" % 1.2345
1.2345.round 2
楼主可以试试 jruby 9030, 提升了 postfix rescue 的性能和 JIT 的准确率
http://blog.jruby.org/2015/10/performance_improvements_in_jruby_9030/
升级后我的 zsh 没任何问题,不用 omz 的好处~
不能复制,不能序列化,只能用 model
其实 jruby 的解释模式比 cruby 慢,jruby 的速度只能提现在 jit 和 GC 上。近来 cruby 已经有分代 GC 所以 GC 方面的表现已经接近了。
jvm 的 compact GC 决定了 jruby 对象要暴露给 C 扩展需要在内存中 pin 住并返回 handle 代替,如果你用的 gem 里用 C 扩展的比较多,就会很慢 (rails 有几个依赖是要编译的哈)
在字符串的内码表示上,jvm 需要在 utf-16 和 utf-8 之间转换也会有些额外开销
几个可能:
用 10 进制 parse integer
bling hashes 那几种实现中多是有巨大 hash clash 漏洞的,其实应该用 murmur3 或者 siphash 加随机启动种子
楼主是巨魔,大家散了吧
:thumbsup:
借位算术
born = Time.new 1999, 1, 1
now = Time.now
d = now.day - born.day
if underflow = (d < 0)
d += 30
end
m = now.month - born.month
m -= 1 if underflow
if underflow = (m < 0)
m += 12
end
y = now.year - born.year
y -= 1 if underflow
puts "#{y}岁#{m}月#{d}天"
或者 time diff hack:
born = Time.new 1999, 1, 1
now = Time.now
time_diff = Time.at(now - born + (born.year - 1970).years).utc
y, m, d, h, mm, s = time_diff.strftime("%Y %m %d %H %M %S").split.map &:to_i
puts "#{y-born.year}岁#{m-1}月#{d-1}天#{h}小时#{mm}分#{s}秒"
估计他没看到 a[m+1]
而且没听明白你说的话,和面试官有关没办法
#21 楼 @xiongmaojames 想要别人给你摘星星,不给就大哭大闹...
粗答案:用户每次请求会带上 cookie, 一般是 cookie 里带了 session 数据
而更好的,对你更有益处的答案就是 "google 一下" 和 "看点基础"
apple 的下载中并没有提供 hash, app store 更新不会断点续传,经常说 an error occurs 就断了...
现在手机浏览的时代,用户对框架大小是非常敏感的,能裁掉一点就一点
polymer 缺点就是太大了,如果只用 webcomponents.js 就小很多 (我觉得有 document.registerElement()
这个 API 就可以了)
component 专用的样式比较容易隔离,选择器前面加 component 名就可以 component 的渲染可以选自己喜欢的模板或者 view renderer component 的事件,用 jQuery/Zepto 在容器元素上注册代理,模板重绘了也不影响,当然也有一些支持绑定事件的 view renderer
webcomponents.js 加任选一个轻量路由 (turbolinks, spine), 再加个 zepto 还是非常轻量。
另外一个不错的方案是 riot.js, 把 web component 和 react-like render 组合到一起了,而且还只有 12.5k, 比 polymer 轻量多了
condition variable 的 using pattern 是
mutex.lock
while <<some-condition>>
cv.wait mutex
end
<<do-something>>
mutex.unlock
主要效用是 broadcast
对于这个一个生产者 - 多消费者问题,得用两个 condition variable, 一个生产者等待 empty_cv, 消费者等待 fill_cv
def main_method
mutex = Mutex.new
fill_cv = ConditionVariable.new
empty_cv = ConditionVariable.new
consumer_count = 3
product_count = 0
value = nil
producer = Thread.new do
@arr.each { |a|
mutex.synchronize do
while product_count > 0
empty_cv.wait mutex
end
value = a
product_count = consumer_count
fill_cv.broadcast
end
}
end
consumers = consumer_count.times.map do
Thread.new do
while producer.alive?
mutex.synchronize do
while product_count == 0
fill_cv.wait mutex
end
@arr_mutex << value
product_count -= 1
empty_cv.signal
end
end
end
end
empty_cv.signal
consumers.each &:join
end
#1 楼 @lidashuang toml 支持日期和时间
最近在看前后端合一的 meteor 和 opal/volt ... 感觉和现在做异构计算的方向有一些相似性。但是异构计算做得深入得多,有时真做到了一段代码不用关心它是在客户端还是在服务器端运行的程度,编译器会帮你优化成最合适的方式。
如果说数据库是后端,服务器也是前端; 如果做系统的是后端,做应用的就是前端; 如果说做硬件的是后端,写软件的也是前端。前后都是相对的 每个分离的层面,都有大量的相似的问题,某些看似新鲜的玩具,在别人眼里说不定只是又一次重复发明而已
另外目光短浅的我谢谢你的同情 -_-
而我"感到沮丧"段说的是调查者,不是你... 因为调查者说
I would expect this number to decrease over time as people’s knowledge of ES2015 increases and move back towards using native JavaScript and smaller libraries.
如果你没有觉得 Vanilla JS 优于 jQuery 的意思,我向你道歉,我把原作者和你合一起开地图炮了。
看到 jQuery 和测试工具的结果还是令人挺沮丧的啊,尽管这两年前端发展日新月异,可是总体水平提升还是有点赶不上。
潜台词是不是觉得用 jQuery 舒服,就是水平低?
现在的趋势就是真正在干活的人被 前后端分离信仰和 micro service 神教夹击 -_-
你觉得 Vanilla JS 优于用 jQuery, 但是想尽快完成任务的人不一定会这么想,因为实施起来还需要 Modernizr 检测载入 Polyfill, 要编译 ECMAScript 到 Javascript, 而且标准 API 写起来都特别长,也没有 $.css()
, $.addClass()
这些工具。
我也感到沮丧,因为调查者觉得自己的工具和理念比 jQuery 优越,但他却完全不提 Elm, ClojureScript, LiveScript 等前端语言,以为前端都得围绕着 JavaScript 转,这也是一种狭隘和 staying in the comfort zone. 一些框架里设计的半吊子 DSL, 换个语言就会清爽简洁得多并且容易调试得多
另外我说的臃肿框架,还包括 jQuery-UI 和很多膨胀的 jQuery 插件,但不包括 React 等简单的渲染库。
jQuery / Zepto 实用又轻量,我可以用它做任何事情 而那些臃肿的框架,经常做点简单事情都会查到未 fix 的 github issue...
h.has_key? :enabled