jianingy 最近的时间轴更新 jianingy 最近的时间轴更新 |
jianingyV2EX 第 27900 号会员，加入于 2012-10-10 10:34:30 +08:00 |
jianingy 最近回复了
2012-11-01 17:10:32 +08:00 回复了 nodenode 创建的主题 › MySQL › PostgreSQL和MySQL配InnoDB各自合适哪些类型的业务模式？ |
至于业务模式的问题，如果是传统的数据库问题。两者差距不大。只有当数据结构上需要做特殊处理时，pg才略显优势。比如我曾经把一个57张表的树形关联数据用pg的hstore/ltree改写成2张表，查询性能极大提升。
2012-11-01 17:04:08 +08:00 回复了 nodenode 创建的主题 › MySQL › PostgreSQL和MySQL配InnoDB各自合适哪些类型的业务模式？ |
我大学用了2年mysql，工作后用了5年pg，不算专业用户。我的一点体会是，pg比mysql更严谨。当然这种严谨往往被人当成pg不易用的借口。有些数据稍有问题是不能被reload回pg的，但是mysql就能接受这种数据，比如有encoding问题的。pg的服务端扩展比mysql要强大。这也就是为什么可以出现类似hstore的列存储和dblink这种跨服务器查询的插件；以及类似ip地址等扩展数据结构。pg 9.0之后一直被人诟病的主从同步问题也被基本解决了，在集群方面也可以匹敌mysql了。然而，大多人所熟悉的还是mysql，所以在项目中贸然使用pg可能遭到一些质疑。
2012-10-17 08:49:55 +08:00 回复了 TNT 创建的主题 › MySQL › LINUX 下无法更改MYSQL所属组。 |
–R 里面 - 打成全角了
2012-10-10 16:40:56 +08:00 回复了 sqrabs 创建的主题 › Python › 为什么Python要以打印日志为荣 , 以单步跟踪为耻？ |
@013231 其实打印日志的问题上我们的理解也点不同。打印运行日志是必要的也是很有技巧的，大部分生产问题都可以通过运行日志定位。而我所尽量规避的是通过不停在代码中加print语句来调试程序的方式。
2012-10-10 13:40:36 +08:00 回复了 stackpop 创建的主题 › 云计算 › 阿里云主机，不小心rm -rf 代码了，还有得救么~~~ |
如果文件系统是ext2或者ext3 不小心 rm 代码后要马上 umount 分区，不能 umount 的立即 mount -o remount,ro 变成只读。然后通过 debugfs 命令找到对应的 inode 直接恢复回来。
可以搜索 debugfs undelete file 找到相关用法
可以搜索 debugfs undelete file 找到相关用法
2012-10-10 10:38:24 +08:00 回复了 sqrabs 创建的主题 › Python › 为什么Python要以打印日志为荣 , 以单步跟踪为耻？ |
@013231 单步跟踪可以用breakpoints的
一直用print大法调试，现在正努力摆脱中。原因有两个，一个是学了functional programming另一个是看了rob pike的一个建议。把rob pike的帖子贴这里，这才是正确的debug方法，
A year or two after I'd joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all. When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model.
Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.
I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.
一直用print大法调试，现在正努力摆脱中。原因有两个，一个是学了functional programming另一个是看了rob pike的一个建议。把rob pike的帖子贴这里，这才是正确的debug方法，
A year or two after I'd joined the Labs, I was pair programming with Ken Thompson on an on-the-fly compiler for a little interactive graphics language designed by Gerard Holzmann. I was the faster typist, so I was at the keyboard and Ken was standing behind me as we programmed. We were working fast, and things broke, often visibly—it was a graphics language, after all. When something went wrong, I'd reflexively start to dig in to the problem, examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think, ignoring me and the code we'd just written. After a while I noticed a pattern: Ken would often understand the problem before I would, and would suddenly announce, "I know what's wrong." He was usually correct. I realized that Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about *how* that problem could happen, he'd intuit where the model was wrong or where our code must not be satisfying the model.
Ken taught me that thinking before debugging is extremely important. If you dive into the bug, you tend to fix the local issue in the code, but if you think about the bug first, how the bug came to be, you often find and correct a higher-level problem in the code that will improve the design and prevent further bugs.
I recognize this is largely a matter of style. Some people insist on line-by-line tool-driven debugging for everything. But I now believe that thinking—without looking at the code—is the best debugging tool of all, because it leads to better software.
Select Language