spring boot 对 sqlite 支持不好,要 copy past 一堆代码,很麻烦。RoR 直接引入。
schema 和 migration 可以没有(我不知道有没有,有你可以说),RoR 默认有。
console 似乎是有,这个我不确定,但用起来似乎是很麻烦。当然,如果你有更好的办法,我也愿意学习。
我只是委婉的告诉你,这几点,我认为 spring boot 做的不怎么样。当然,如果你觉得做的好,也请说出你的理由。因为看你之前的回复,你对 Spring Boot 和 RoR 都很了解(因为你说他们一样,所以我认为,你很了解两者),希望可以向你学习。
难道 Java 流行只是因为功能太少?
这种句式一点意义都没有,几十年前还流行打鸡血呢,现在还流行注射中草药呢。
你说 SB 和 RoR 一样,就举出例子来。你知道 java 为什么流行,就说出来。
流行本身就没有什么意义,然后抛出了一个疑问句,没有任何依据,就更没意义。
我想知道 sping boot 怎么用 sqlite,schema 在哪,migration 怎么用,console 怎么用。。
牛逼!
有的时候,人们在谈性能的时候,都忘了说是 IO 密集型,还是 CPU 密集型。
当初定技术栈的时候,为啥选 C?性能原因?
Ruby 不像 Clojure 对这个东西那么急切(我不是说 Ruby 不需要)。
Clojure 很需要这个东西,是因为,Clojure 把 map 当对象用,把 map 的字段当方法用,Ruby 有对象,对象有啥方法、字段都是相对明确的。
TF 是啥?
具体说说?
ruby-china 的影响力: 如果学习后端技术,最好的方法是 clone ruby-china 论坛。 如果学习前端技术,最好的方法是 clone ruby-china 客户端。 如果想宣传某门语言,最好的方法是,用这门语言做一个论坛。
要改下标题,现在是 5k 了
明白,看来八成是 cpu 密集型任务,多线程没啥意义。亦或是 sidkiq 调度多任务的时候,消耗比较大……
我是觉得产品的需求不如用户故事靠谱 ,不过这个只是我个人经验,可能不是很有参考价值。。。
推行敏捷、或者项目管理,在软件公司挺难的,教给别人就更不容易了
大部分的 Scrum 团队,都只是在玩 Scrum 过程的团队而已。
有的对敏捷了解比较少,有的只是走个过场,却不知道这些工具、方法是为了解决什么问题而存在的。知其然,不知其所以然。
为啥不用多线程做?ruby 多线程不靠谱吗?
cucumber 首先是沟通工具,减少产品和开发之间的认知差距。 cucumber 之后才是自动化工具 用 cucumber 的话,就要搭上一个开发,测试搞不定。测试还有其他自动化工具,cucumber 这是看起来对开发友好。
如果把 cucumber 当沟通工具,写写用户故事就可以了,挺好的。 如果当做自动化工具,只能说仁者见仁了。
那个 gem 还真没了解过
进程调度问题
给每个用户 100 个额度,用完了再分配。
第一个和第二个问题 假设 A 算 1000 个单位,就先让他算 100 个,算完了再分给他 100。这个时候,B 进来了,B 插入 100 个任务,B 就会先算完。
第三个问题 加优先级就可以,爸爸们都放到爸爸队列里,爸爸们有任务,就先算爸爸的。还可以,如果是爸爸,就分配 200 个单位。
还可以从需求上解决,比如算完 1 个就给反馈什么的。
但说身体这一条,我有一个朋友在大学当老师,一周几节课,身体也不好。。。因为管不住吃、喝,还不运动。
如果仅仅是身体的话,早睡加上运动,会好很多(不过做到这些也挺难的)。
ror 应该是把配置读到某个对象里(ruby 几乎啥都是对象),更新配置,在 reload 这个对象应该就可以了。
如果有很多服务,有需要有统一的配置,比如 reids、mysql,就用配置中心。觉得配置中心麻烦,可以放到 reids 里。
关键是内存里的要 refresh,还不如重新部署一次…
JRuby?
你是想说,纯粹从算法比较的角度来讲,这两个算法有本质的区别,所以不能直接比较?
这篇文章是从具体问题出发,提出解决方案,并做比较。算法是为解决实际问题而存在的。
我想了一下,还是说出我的想法吧。
数据结构是靠约束来定义的,如果约束不满足,就不能叫这个数据结构了。就好比偶数,能被 2 整除的数,是偶数。如果不能被 2 整除,就不是偶数。
不理解不恰当的地方, 这个是对拼写检查这个问题,提出了四种解决方案,然后并做比较,在实际应用中,也会在 bit map 和 bloom filter 之间做选择。 bloom filter 在拼写检查中,如果出现 false positive,结果就是一个错误(没在字典里)的拼写,认为是正确的,这个在拼写检查里,一般是可以接受的。
就想 #9 说的那样,用一个 job 轮询查有哪些商品到期了,这样有一个 job 做检查就可以了。时间间隔看需求来定。可能要看下对列怎么处理 repeat job 的,假设时间间隔是 200 毫秒。第一个 200 毫秒到了,处理时间,但花了 200 毫秒,还没处理完,那这个时候,是同时做处理,还是说等第一个处理完,然后再做第二个。如果是处理完第一个,再处理第二个,假设第一个花了 405 毫秒,那是马上做第二个处理,还是说,要等第 600 毫秒才处理(这样的话就有延迟,js repeat 是这么处理的)。
应该有两类 job,一类 job 做检查到期,一类 job 做后续操作,至少要用两个独立的 job queue,两者不能相互影响(第二类 job 跑满 cpu 的时候,第一类 job 要能正常工作),优先级应该能解决,但最好还是测一下。
midori 性能会提升不少吧?
有,不多。广州游戏公司用的比较多。有些 im 也是用 erlang,比如去哪的 im,比如我们。
刚好有个项目要连多个数据库。
然后 lisp 粉各种瞧不起大 JavaScript
Clojure 是这种
m = {}
m = (assoc m {:a => 1})
写起来容易,状态变化不那么清晰。
Erlang 的话是,
M = {}
M2 = maps:update(a, 1, M)
写起来麻烦,但状态辩护会更清晰。