V2EX › luikore 的所有回复 › 第 14 页 / 共 27 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 10 11 12 13 14 15 16 17 18 19 ... 27

❮

❯

2013-08-24 11:09:45 +08:00

回复了 scusjs 创建的主题 › 云计算 › 百度1T永久空间，真的会永久？

很多大文件都是同样的, 商家只用维护一个巨大的哈希表, 发现是大文件就去查表, 只存一份或几份, 其实每人 1T 耗费的硬件资源远比你们想像的少

2013-08-22 20:54:10 +08:00

回复了 Kai 创建的主题 › macOS › A Polyglot Database Client for Mac OS X

匆忙赶到 github 上给星, 发现已经 2300 多了...
https://github.com/Induction/Induction

2013-08-22 13:18:07 +08:00

回复了 Livid 创建的主题 › Python › 最近的攻击让我想到的一些事情

@ipconfiger redis cache 住瓶颈就好了... 扔掉 ORM 200ms 最多也就变成 50ms 吧, 没有擦车的效果好.

另外伪造瓶颈页面也是一种防御手段 -_-

找到根源效果更治本, 例如发这个帖把攻击者钓出来...

2013-08-22 09:08:38 +08:00

回复了 pythonee 创建的主题 › 程序员 › 每种语言在各个公司的是如何被使用的

我能吐槽 twitter 现在 session 还是用着 ruby 独有的序列化方式却在忽悠别人用 scala 么...

2013-08-22 00:17:54 +08:00

回复了 Elix 创建的主题 › 美酒与美食 › 鸡翅之后，发个宵夜！#深夜食堂报复社会

求方形的烤馕...

2013-08-21 16:15:02 +08:00

回复了 fucktwice 创建的主题 › 问与答 › 我感觉有时候往往出现这种情况,代码越美观,结构越好,或者用了更多的设计模式,会大大的增加人对业务逻辑的学习和接收难度,这是怎么回事?

@otakustay “观察、订阅、分发”模式也是一个类比的设计模式(有人会把它升华到"夹沟模式"), 除此之外什么都没有说, 看到的人可能以为自己"理解"了, 但其实最后看代码才知道是什么回事. 两个人脱离实际讨论一个假大空设计模式, 很可能说的完全不是一回事, "这类概念可以交流"是个错觉而已.

光就 pattern 这个词来说, 在 "设计模式", "代码模式", "模式识别", "模式匹配", "正则模式" 语境下意思各不相同. 还有博大精深语把 mode 也翻译成 "模式", 进一步把浆糊搅得更浑, 造成微妙的"深刻"的错觉. 你说的"模式"如果不是设计模式, 那到底是什么? 如果没有一个人人都同意的准确定义, 那这个概念就是不值得讨论的, 也无法对我们的代码产生有意义的影响.

2013-08-21 15:41:54 +08:00

@otakustay 我一直指的设计模式. 广义的"模式", 含义太广泛, 不是 well-defined 的概念没什么好讨论的...

一种是正常人的思路, 看到问题去想怎么解决, 然后自然形成的代码结构和项目结构, 容易看懂容易改.

一种是架构太空人的思路, 先套用各种模式作出结构来, 再把问题交给别人解决, 太空人的理解(我们常常把"习惯"当"理解"用)和一般人区别越大, 就越难看懂和修改.

2013-08-21 15:02:07 +08:00

@otakustay 反了, 是先有工程师设计出了使用事件的系统, 然后才被人总结成设计模式...

在表达力比较弱的语言里, 用设计模式写的 XxxSingleton, 就得自己写 getInstance. 抄/背诵/IDE生成和拷贝粘贴是一回事.

用元编程实现的 XxxSingleton, 你不用自己写 getInstance, 它实际上就是个 API call 了, 叫不叫设计模式都没影响, 也避免了无谓的重复.

2013-08-21 13:51:54 +08:00

@ksc010 模式和 vim 完全相反: 用了模式后, 总代码量会增加, 但用了 vim, 总按键量会减少.

如果一个模式可以重用, 它就是个 api call 而不是模式了. 模式说白了就是复制粘贴一坨东西然后改改名字调个顺序, 这就违反了软件设计的三原则(DRY, KISS, YAGNI)之一: don't repeat yourself.

随着编程语言不断添加特性和库的增强, 需要用到模式的场景会越来越少. 语言的特性需要学习去理解, 模式就是个类比根本就不存在学习这回事(个别名字起得很晦涩的模式除外)... 模式在不会模板元编程的 C++ 程序员和不会函数式编程的 java 程序员中特别流行. 就 java 说, 很多模式要做的事情现在直接加个 annotation 就可以了, 不需要一遍又一遍的重复拷贝那些错漏百出的实现...

2013-08-21 13:34:58 +08:00

@otakustay 易学不代表容易维护, 但以为难学就容易维护升级就错了...

2013-08-21 13:10:21 +08:00

回复了 missdeer 创建的主题 › 分享创造 › 正在写一个代码编辑器，Windows/Mac平台的，vim/emacs党请略过

是 qt 么? 工具栏其实可以喀嚓掉...

2013-08-21 13:07:59 +08:00

回复了 missdeer 创建的主题 › 分享创造 › 正在写一个代码编辑器，Windows/Mac平台的，vim/emacs党请略过

gtk? mac 上绝对没人用基于 gtk 的界面的

2013-08-21 12:53:34 +08:00

回复了 sethverlo 创建的主题 › 问与答 › 请问你们用脚本语言（Ruby/Python）写程序的时候碰到诡异的问题都怎么调试？

@sethverlo print 是为了知道运行时发生了什么事情, 没法 print 才用 log, 不知道是否正常才看 log, 这是不得已而为之... 滥用 log 就是连锁反应: 搞 rolling, 压缩, 合并, 日志分析... 本来简单的事情都变得很复杂了.

map-reduce 查出一个 bug 还不如当初写个测试...

2013-08-21 00:52:58 +08:00

回复了 sethverlo 创建的主题 › 问与答 › 请问你们用脚本语言（Ruby/Python）写程序的时候碰到诡异的问题都怎么调试？

开发环境查虫用 print, 线上产品查虫用 log... 不过 print/log 就能搞定的问题往往都是超简单的.

疑难问题还是 debug 和 repl 比较有效率, 这些往往都是上下文依赖关系比较强的地方, 看到第一步的结果你才会去想或者试探下一步, 一个交互能力比较强的环境比预设的日志省事多了.

顺便, 写测试你只多花一倍时间, 没写测试去查问题, 要多花十倍时间...

2013-08-21 00:39:43 +08:00

回复了 sethverlo 创建的主题 › 问与答 › 请问你们用脚本语言（Ruby/Python）写程序的时候碰到诡异的问题都怎么调试？

@sethverlo <% binding.pry %>

2013-08-20 17:53:30 +08:00

回复了 sethverlo 创建的主题 › 问与答 › 请问你们用脚本语言（Ruby/Python）写程序的时候碰到诡异的问题都怎么调试？

代码中插一行 binding.pry, 想看什么都可以, 还能 edit-method 直接打开方法的源代码编辑

2013-08-20 10:53:01 +08:00

"美观", "好" 是因人而异的主观概念
抽象必然导致难懂, 设计模式, 是给不懂抽象的人来装懂用的

2013-08-19 19:35:13 +08:00

回复了 gyteng 创建的主题 › 宠物 › 养猫一定要把窗和阳台封死吗？

猫很好奇, 有机会一定会跳的. 4, 5层楼的话应该摔不伤, 朋友公司的猫从 9 楼跳下去摔断了一条腿 (虽然可能是因为它老是被喂西瓜或者火腿肠这种不带肉的东西而想不开了...). 20 楼跳下去可能有生命危险, 不过如果是身手矫健又能展开四肢成降落伞状的猫, 可以试试挑战下极限.

2013-08-18 02:18:09 +08:00