乐者为王

Do one thing, and do it well.

PBL文件格式解析

PBL文件是PowerBuilder库文件,在其中存储了应用程序所使用到的所有系统对象和用户自定义对象的集合,同时PBL文件中还存储了源代码控制信息(Source Code Control,简称SCC)。对其文件格式的研究,可以准确地了解程序结构并能对PBL文件中的对象进行修改,同时也有利于库文件的修复,程序动态执行等方面的工作。

PBL文件的存储结构

PBL文件存储信息时是以块(Block)为单位为对象分配存储空间的,每个块的大小固定为512字节,块号从0开始计算,块号与块首字节的偏移地址有如下关系:

1
块号 = 块首字节的偏移地址 / 512

整个PBL文件由Header块、Bitmap块、Node块、Data块组成。其中除Header块外,其它块均以链表结构组织,其中Data块是Node块中Entry表项的具体内容,是从属于Node块的。下图说明了这些块的关系。

图中Header块、首个Bitmap块及首个Node块在存储空间上是相邻的,其中Node块比较特别,占6个块共3072字节,其余块只占512字节,其空间大小及起始地址如下表所示:

块号 地址范围 描述
0 0000-01FF Header块
1 0200-03FF 首个Bitmap块
2-7 0400-0FFF 首个Node块

Header块解析

Header块是整个PBL的描述信息,它包含了PBL的版本标志,库注释,首个SCC数据块的偏移地址等信息。具体内容如下表所示:

块内地址范围 所占字节 数据类型 描述
0000-0003 4 char 'HDR*'
0004-0011 14 char 'PowerBuilder' + 0x00 + 0x00
0012-0015 4 char PBL格式版本(如0900表示9.0版本)
0016-0019 4 long 创建/修改日期时间
001A-001B 2 byte 保留
001C-011B 256 char 库注释
011C-011F 4 long 首个SCC数据块的偏移地址
0120-0123 4 long SCC数据块实际大小
0124-01FF 220 byte 保留

Bitmap块解析

Bitmap块中存放的是表示PBL文件存储空间的使用情况。该块数据结构如下表所示:

块内地址范围 所占字节 数据类型 描述
0000-0003 4 char 'FRE*'
0004-0007 4 long 下一个Bitmap块的偏移地址或0
0008-01FF 504 bit 位图(每个位标识一个块)

由上表可知,包含一个Bitmap块的PBL文件最多可使用504 * 8 = 4032个块。当文件空间超过4032个块时,就需要使用第二个Bitmap块,它的偏移地址由当前Bitmap块块内偏移0004-0007处的值表示。如果是最后一个Bitmap块,则对应的字节处为00 00 00 00,即偏移地址为0。这样就形成了Bitmap块的单向链表。

位图用于标识块的使用/空闲情况。在位图中为1的位,表示与该位序号对应的块已被使用;反之,表示对应块未使用。例如FF FF 40 00还原为位图则为11111111 11111111 01000000 00000000,该位图表示PBL文件共有18个块,其中的第16号块空闲未使用。

注意:在实际分析多个PBL文件后发现,位图中的位并不能真实反映对应块的空闲/使用情况,只是记录PBL文件使用了多少个块。

Node块解析

Node块是目录块,主要用于存放Entry目录表项。下表是Node块的数据结构:

块内地址范围 所占字节 数据类型 描述
0000-0003 4 char 'NOD*'
0004-0007 4 long 左Node块的偏移地址或0
0008-001B 4 long 父Node块的偏移地址或0
000C-000F 4 long 右Node块的偏移地址或0
0010-0011 2 short 块内可用空间(初始值3040)
0012-0013 2 short 按字母顺序最后一个对象名的位置
0014-0015 2 short 该Node块中的Entry表项数
0016-0017 2 short 按字母顺序第一个对象名的位置
0018-001F 8 char 保留
0020-00BF 3040 chunks Entry目录表

其中Entry目录表是顺序表。当一个Node块的空间不足以存储所有Entry表项时,可以再使用一个Node块来存储,并且Entry表项不能跨Node块存储,因此Node块中的空间不能完全利用,会有一定的剩余,这个值记录在块内偏移0010-0011处。

Node块的链接方式有些复杂,它使用一种称之为三叉链表(节点包含四个域:数据域、左指针域、右指针域、父指针域)的链式存储结构把所有Node块组织成为一颗二叉树,这可能是PowerBuilder为了提高查找速度而做的一些优化吧。

Entry表项解析

每个Entry表项对应于一个对象的源代码或PCODE的描述信息,因此Entry目录表就是整个库中各个对象的索引表,存储了各对象的索引信息。例如,在编程中创建一个名为“pbltest”的Window对象类型,那么在Entry目录表中要存放该对象的两个索引表项,分别为“pbltest.srw”用于存储源代码,“pbltest.win”用于存储PCODE。在Entry目录表中存储的对象有以下这些:

对象类型 源代码后缀 PCODE后辍
Application sra apl
Window srw win
DataWindow srd dwo
Menu srm men
Function srf fun
Query srq -
Structure srs str
User object sru udo
Pipeline srp -
Project srj -
? - pra
? - prp

Entry表项的具体数据结构如下表所示:

块内地址范围 所占字节 数据类型 描述
0000-0003 4 char 'ENT*'
0004-0007 4 char PBL格式版本(如0900表示9.0版本)
0008-000B 4 long 首个Data块的偏移地址
000C-000F 4 long 对象的实际大小
0010-0013 4 long 对象的创建/修改日期时间
0014-0015 2 short 对象的注释长度
0016-0017 2 short 对象名的长度
0018-???? ? char 对象名 + 0x00

这里需要说明的是,每个Entry表项的长度并不是固定的,它随着对象名的长度变化而变化,所以要读取下一个Entry表项,只能通过计算上一个Entry表项的长度即24 + 对象名长度来得 到,或者通过搜索下一个ENT*得到。

Data块解析

在Entry目录表中的各对象的实际数据内容是存储在Data块中的。Data块的数据结构如下表所示:

块内地址范围 所占字节 数据类型 描述
0000-0003 4 char 'DAT*'
0004-0007 4 char 下一个Data块的偏移地址或0
0008-0009 2 short 本块内存储的数据的实际长度
0010-01FF 502 char 对象的实际数据

由上表可知,若对象的数据内容在502字节以上时,就需用多个Data块存放,这些Data块形成一个单向链表。链表的最后一个Data块的0004-0007中存储的偏移地址为00 00 00 00,表示链表结束。0010-01FF处存放的是对象的实际数据,只有最后一个Data块的长度有可能小于502,且以0x00字节表示结束。

根据上面对PBL文件格式的解析,使用Ruby开发了一个小工具,用来输出PBL文件中存储的各种信息。源代码被放在GitHub上面,供大家参考。

代码下载:https://github.com/dohkoos/pblanalyzer

带权随机函数

  • 设计抽奖活动时,我们总是要控制抽奖物品出现的概率,让好的东西很难被抽到;
  • 设计游戏打怪时,我们要控制打怪时的命中概率,要控制宝物掉出的概率;
  • 网站的置顶广告,我们也要根据广告主的广告费用控制广告的出现时间;
  • 设计负载均衡算法时,我们要根据服务器的性能控制服务器被选中的可能。

深入思考这些需求,你会发现它们都有相通的概念:每次从多个候选项中随机选取其中一项,要求每个候选项的出现都有一定的概率。

假设有这样的候选项和对应概率:a:20%,b:25%,c:40%,d:15%。现在,把每个候选项的概率用一个称之为权重的正整数表示(最简单的方法是把百分符号去掉)。那么,

1
实际概率 = 候选项权重 / 权重总和 * 100%

事实上,权重的总和不一定要等于100,可以是任意大小。

算法描述

依次将各候选项的权重从原点开始放在x轴坐标上首尾相连。这样,每个候选项对应一个取值区间,在总区间范围内随机选取一个值,该值所在区间就对应了选中的项。

Ruby代码实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
def random(weight)
  # 获取所有候选项的权重总和
  total_weight = weight.inject { |r, e| r + e }

  # 随机选取一个介于0到权重总和之间的整数
  rand_value = rand(total_weight)  # [0, total_weight)

  # 扫描所有候选项,并且保留候选项权重的累积数。
  # 每当随机数小于累积数时,就停止并选出当前项。
  weight_barrier = 0
  weight.each_index do |i|
    weight_barrier += weight[i]

    break i if rand_value < weight_barrier
  end
end

该实现不能保证每个候选项都恰好按正确的比例被选中,但当次数足够多时,应该会十分接近预先设定的比例。

实际案例

要求写int[] get_weight(int[] weight)函数,返回的是权重的索引。其中weight是权重的数字数组,最终的结果是要大概保证按照给定的比例。

  • 比如weight为[1, 2, 2],那么权重比例为1:2:2,执行10次后,大概的输出是0 1 1 0 1 1 2 2 2 2;
  • 比如weight为[100, 0],那么权重比例为100:0,执行10次后,大概的输出是0 0 0 0 0 0 0 0 0 0;
  • 比如weight为[1, 1],那么权重比例为1:1,执行10次后,大概的输出是0 1 0 1 0 0 1 1 0 1。
1
2
3
4
5
6
7
8
9
10
11
12
def get_weight(weight)
  10.times.map { random(weight) }
end

weight = [1, 2, 2]
puts get_weight(weight).join(' ')

weight = [100, 0]
puts get_weight(weight).join(' ')

weight = [1, 1]
puts get_weight(weight).join(' ')

逻辑题-共打了多少鱼

abcde五人打渔,打完睡觉,a先醒来,扔掉1条鱼,把剩下的分成5份,拿1份走了;b再醒来,也扔掉1条,把剩下的分成5份,拿1份走了;然后cde都按上面的方法取鱼。问他们最少打了多少条鱼?

渔民 醒来时鱼的总数 取走的鱼数
a x1 = x (x1 - 1) / 5
b x2 = 4 * (x1 - 1) / 5 (x2 - 1) / 5
c x3 = 4 * (x2 - 1) / 5 (x3 - 1) / 5
d x4 = 4 * (x3 - 1) / 5 (x4 - 1) / 5
e x5 = 4 * (x4 - 1) / 5 (x5 - 1) / 5

由于扔掉1条鱼后,还能被分成5份,设渔民醒来时鱼的总数为remain,那么(remain - 1) % 5的值为0,即remain % 5的值为1。

最简单的方法就是枚举,最小值从1开始:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
fishmen = [0, 0, 0, 0, 0]  # 渔民取走的鱼数
total = 1

while true do
  remain = total  # 渔民a醒来时鱼的总数
  5.times do |i|  # 5个渔民轮流取鱼
    break if remain % 5 != 1  # 如果不符合扔掉1条鱼后还能分成5份的条件,就枚举下个值
    fishmen[i] = (remain - 1) / 5  # 渔民取走的鱼数
    remain = 4 * fishmen[i]  # 渔民取走鱼后剩下的鱼数
  end
  break if fishmen[4] != 0  # 如果渔民e也取到了鱼,那么就得到了鱼的总数
  total += 1
end

puts total  # 结果是3121条鱼

上面的代码总过做了3901次循环,下面来做进一步的优化。

从表格可以看出,因为(x5 - 1) % 5 == 0,推导出x5 >= 6;又x1 % 5 == 1,因此x1的个位数必须是1或者6。所以,枚举的最小值可以从11开始,每次步进为5。优化后的代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
fishmen = Array.new(n, 0)
total = 11

while true do
  remain = total
  5.times do |i|
    break if remain % 5 != 1
    fishmen[i] = (remain - 1) / 5
    remain = 4 * fishmen[i]
  end
  break if fishmen[4] != 0
  total += 5
end

puts total

总的循环次数减少到1401次,减少了整整64%的循环。

推而广之:n个渔民打渔,每个渔民依次扔掉1条鱼后,把鱼分成n份,然后拿走其中一份,求最少打了多少条鱼?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
fishmen = Array.new(n, 0)
total = 2 * n + 1

while true do
  remain = total
  n.times do |i|
    break if remain % n != 1
    fishmen[i] = (remain - 1) / n
    remain = remain - 1 - fishmen[i]
  end
  break if fishmen[n - 1] != 0
  total += n
end

puts total

这下子无论多少个渔民打渔都可以用这段代码搞定了。我试了试9个渔民,发现竟然可以打近3.9亿条鱼,那得有多少鱼啊!另外,计算时间也明显开始变长了。不知道还能不能做更进一步的优化。如果你有更好的算法,请快点告诉我吧!

写出受欢迎的编程文章的10个技巧

英文原文:http://www.devx.com/blog/2009/01/10-tips-for-writing-consistent.html

对于作者,这是一个可悲的事实。当谈到受大众欢迎时,不是所有的文章都是平等的,一些文章被证明比其它的更受欢迎。事实是,不管你选的主题有多好,或者你写的有多好,你都无法保证每次都能打出本垒打。尽管如此,如果你已经在写编程的文章(或者你正在考虑写),这里列出的技巧被证明能帮助文章从沉闷乏味的堆里跃升至最多查看次数列表的顶部。

1. 选择一个简练的话题

挑选一个简练的话题是艰难的,因为很多有趣的话题一点也不简洁,它们是冗长的和复杂的。有时候你可以创建很好的独立文章作为一个较长的话题,但通常不要这样做。相反,你可能需要写一个系列或一本书。要么选择别的,要么把这个话题分成简练的块。

接下来的几个技巧可以帮助你满足技巧#1的要求:

2. 增强现有的文档

一些最受欢迎的文章本质上是增强文档。那并没有什么错,因为技术文档通常是匆忙产生的,是不完整的,不是由开发者编写的,或缺乏相关的例子。在几乎所有情况下,文档(或文档的缺乏)给作者提供了丰富的话题。

3. 比较事物

另一个屡屡受欢迎的策略是写比较两个或多个受欢迎的项目的文章。这些可以是语言、语言版本、APIs、数据库、操作系统、框架、编程方法、模式——在快速变化的开发者世界中,有着无数的机会。挑两个或多个开发者使用的技术,并且写那种最好能帮助开发者转型或选择它们的文章。

4. 列个清单

你可能会认为这是陈词滥调,但“10 for/about”类型的文章往往表现的很好。(如果这篇博文做的很好,我会认为它验证了这个观点,如果没有的话,或许我会减少成“9个技巧……”)。编辑们和出版商们喜欢这些文章,因为读者喜欢它们。我怀疑读者喜欢它们是因为包含很多内容的文章增加了概率,因为这些文章至少包含有一个需要的或有趣的材料,但也许人们只是喜欢列表。无论如何……

在你有一个坚实的话题后,你准备开始写作,请记住这些观点:

5. 忽视历史

是的,我知道你认为每个人在切入正题前都需要了解特定主题的历史背景,但事实是,他们很少这样做。比起你在高中学习代数时让你的父亲解释数学的历史,你的读者不再想思考你的历史评论。这里有个读者行为分析的内部技巧:大部分读者从来没有读完过第一页。所以,如果你没有回答他们的问题,或立即抓住他们的兴趣,不管你的文章的其余部分有多么正确,他们都不会看。链接到历史,切入正题。

6. 避免“HelloWorld”例子

在你读过的文章和书里你看到过一千个“HelloWorld”的代码例子,但这并不意味着它们是好的!它们不是。没有人喜欢它们。对于学习编程的任何事情它们是完全无用的。它们也不是娱乐。完全有可能写出清晰而简单的既可以教又不烦闷的例子。

7. 说明你的观点

开发者喜欢代码,的确,但你也可以通过包含插图和截图帮他们节省时间和精力。这是因为他们中的许多人可能不会运行你那迷人的示例代码,但如果他们正在阅读你的文章,他们很可能对结果感兴趣。显示输入或输出无论何时都很重要。

8. 显示有趣的代码

许多技术作者似乎认为,在简短的解释之后提供大量的示例代码(或者更糟糕的是,只是显示代码而没有解释)将刺激他们的读者研究代码以获得启示。我向你保证那不是真的。最好的文章解释了话题,但只显示代码片断,然后解释或说明(或两者)代码做了什么,它如何与周围的代码或整体的话题适应,什么时候你应该使用它,什么时候不应该,也只有到那时——仅且当它是真正有用的时候——他们会向你打听更长的代码块。相反,只放有趣的代码在你的文章里,并将其余部分作为可运行的、完整的项目以供下载。

9. 化繁为简

避免冲动去告诉人们你的主题是多么地复杂。他们知道它是复杂的,或者他们很可能不会读你的文章。相反,想办法去让复杂的主题看起来更简单。

也许是所有技巧中最重要的一点:

10. 简明扼要

最受欢迎的技术文章只给读者他们需要的——没有更多。

最后,这是真的,有些文章很受欢迎,尽管它很少有甚至没有在这里列出的特性——但那并不是你可以控制的东西。尝试去写那种文章就像是博顺子,你会浪费大部分的时间。专注于基础,写大量的文章,然后其中的某些人将会成为赢家。

快乐写作。

在Application对象里存储数据的陷阱

看到Don't Store Data in the Application Object讲,在Application对象中存储共享数据会引起NullPointerException。顿时心里就咯噔了一下,用了四分之三秒,想起自己有个业余项目就干了这样的事。赶紧地测试看看。

打开应用,从MainActivity进入TxtViewerActivity界面(这里MainActivity主要是读取目录数据,然后保存在继承自Application的MainApp中,供TxtViewerActivity调用)。按手机Home键退出应用,这时你按菜单键可以看到该应用的缩图。然后在Eclipse中打开Window -> Show View -> Other -> Android -> Devices视图,双击窗口内的设备,然后点击设备下对应的进程,点击右上方红色的“Stop Process”图标。

重新按菜单键打开应用,然后……然后果然在LogCat中看到了有NullPointerException的大段红色警告文字。

为什么会Crash的?

根本原因在于:当应用被kill掉后,通过菜单键重新打开时,应用不会开始重新启动。Android系统会新建一个Application对象,然后启动上次离开时的TxtViewerActivity以造成这个应用从来没有被kill掉的假象。因为没有经过MainActivity的数据读取,所以在TxtViewerActivity中读取数据当然要抛出异常了。

有没有替代方法呢?

  • 直接将数据通过Intent传递给TxtViewerActivity?当然也会碰到上述同样的问题。
  • 使用SharedPreferences?可惜只能存储boolean、int、long、float和String五种数据类型,不支持List的存储;
  • 使用持久化存储?也不支持List的存储,而且太笨重了;
  • 使用Singleton对象保存共享数据,然后通过Intent传递呢?这个想法不错,还可以将读取assets资源等操作移到该对象中,做到单一职责原则,改善设计。不过这样一来Singleton对象会对MainActivity的context有长期引用,容易造成内存泄露。如果不把读取操作放进去……那根本就不可能,你能让一个追求完美的程序猿忍受糟糕的代码设计吗!

幸好早就有人总结出来经验了:使用Application的context代替Activity的context。

创建Singleton对象,在Application对该对象保持引用,把原来存储在Application中共享的数据全部移到Singleton对象中,将Activity中读取assets资源等操作也放入该对象,Activity中原来对Application对象的访问改成通过Application对象对Singleton对象的访问。

这样修改后,不光解决了应用的崩溃,还预防了内存泄漏,更改进代码的设计。

代码下载:https://github.com/dohkoos/txtReader

一开始就编写优质的OO代码

英文原文:https://weblogs.java.net/blog/2008/10/03/writing-great-oo-code-day-one

没有获取经验的捷径。编写良好的面向对象代码需要经验。尽管如此,这里有三个实践可以帮助你一开始就有个良好的开端:

  1. 使用测试驱动开发(TDD)编写你所有的代码
  2. 遵循简单的规则
  3. 命令代替询问(Tell Don't Ask)

使用TDD编写你所有的代码

测试先行编写的代码和测试后行编写的代码是非常非常不同的代码。测试先行编写的代码是松耦合和高内聚的。测试后行编写的代码往往会破坏封装,当一些属性或私有方法需要被暴露给测试的时候,因为这些类没有被设计成要被测试的。如果你编写的代码测试先行,代码的依赖性会更好,你的代码将是松耦合和高内聚的。稍后详细讨论测试如何帮助你设计更好的代码。

遵循简单的规则

代码是简洁的,当它:

  1. 通过所有的测试
  2. 不包含重复代码
  3. 表达了所有的意图
  4. 使用了最少的类和方法

重要的是注意到我使用了一个有序列表。顺序很重要。带有单一main()方法的单一GodClass并不简单。它可以通过所有的测试,但在比“Hello, world!”更复杂的任何程序里它一定会包含重复代码和没有表达所有的意图。

我与简单的规则的斗争重点围绕在If Bug 。我不明白遵循简单的规则如何阻止某人编写大量的if代码。有人会说,我试过了,大量的if代码不会表达意图。但是,当你读到这样的代码

1
2
3
if (mobile.getType() == MobileTypes.STANDARD) {
    alert();
}

它实在是太容易看出意图了。无论该代码是在哪个方法的上下文中,如果mobile是STANDARD类型,那么警报。你还需要多少意图?

然后我灵光小闪。如果有那样的代码,那么在代码的其它地方肯定还有更多。可能是这样的代码:

1
2
3
if (mobile.getType() == MobileTypes.GAS) {
    registerGasReading();
}

1
2
3
if (mobile.getType() == MobileTypes.TEXT) {
    sendTextMessage();
}

1
2
3
if (mobile.getType() == MobileTypes.LOCATION) {
    notifyLocation();
}

你看见了吗?我当然知道。违反规则2。许多许多违反规则2。并且是违反规则2的最糟糕的那种。重复代码在许多不同的代码片段中。重复代码将非常非常难被找到。所以为了帮助防止这个,我列出来了。

命令代替询问

命令代替询问意味着不要询问一个对象的状态然后做些什么。应该命令那个对象去做些什么。这意味着所有这些if例子变成了:

1
mobile.alert();

1
mobile.registerGasReading();

1
mobile.sendTextMessage();

1
mobile.notifyLocation();

现在假设有一些if子句散落在有重复实现的整个代码中。在那个大量if代码的版本中,它们将非常难被找到,但在命令代替询问版本中,所有的实现都在Mobile类中。所有的都在一个地方寻找和消除。

聆听你的测试也将帮助你保持代码简单。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public interface Alarm {
    void alert(Mobile mobile);
}

public class Siren implements Alarm {
    public void alert(Mobile mobile) {
    if (mobile.getType == MobileTypes.STANDARD) {
        soundSiren();
    }
  }
}

public class SirenTest extends TestCase {
    public void testAlert() {
        LocationMobile mobile = new LocationMobile();
        Siren siren = new Siren();
        siren.alert(mobile);
        assert(sirenSounded());
    }
}

如果你仔细聆听你的测试,它会问你,“你为什么需要LocationMobile去测试Siren?”是呀,为什么呢?似乎Siren甚至不应该知道LocationMobile。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class LocationMobile {
    private Alarm alarm;
    public LocationMobile(Alarm alarm) {
        this.alarm = alarm;
    }
    public void alert() {
        alarm.alert();    // alert on Alarm no longer needs a mobile
    }
}

public class LocationMobileTest extends TestCase {
    public void testAlert() {
        Alarm alarm = EasyMock.createMock(Alarm.class);
        alarm.alert();
        EasyMock.replay(alarm);
        Mobile mobile = new LocationMobile(alarm);
        mobile.alert();
        EasyMock.verify(alarm);
    }
}

看上去我仅仅互换了依赖。作为Alarm依赖Mobile的替换,现在有了Mobile依赖Alarm。如果你仔细看第一个测试,真正的依赖是Siren知道LocationMobile。一个具体类依赖于另一个具体类。这违反了依赖倒置原则 (DIP)。第二个例子是LocationMobile依赖接口Alarm。一个具体类依赖一个抽象。这满足了DIP。

如果你使用TDD编写你所有的代码,遵循简单的规则,以及命令代替询问,那么你会在那条成为一个更好的OO程序员的路上。良好的OO代码容易阅读和维护,但是可能难于编写。至少开始是这样。你写得越多,你将会变得更好,你将得到的经验也越多。与此同时,这些实践会让你在你的路上走得更好。

Ruby调试工具概览

调试Ruby代码最简单的方式就是使用puts或p方法。当有很多变量需要查看时,到处添加puts或p方法就可能变的不那么实际。幸好,Ruby社区提供了许多强大的调试工具。

Ruby 1.8+时代

调试Ruby代码使用ruby-debug。调试Rails代码则是pry-nav。不过在Ruby 1.9出来后ruby-debug就有问题了,于是就有了ruby-debug19,一个针对Ruby 1.9的ruby-debug移植版本。

Ruby 1.9.2+时代

等到Ruby 1.9.2发布,ruby-debug彻底歇菜,然后debugger就出现了。pry-nav也不好使了,还好有pry-debugger

Ruby 2+时代

新的Ruby调试工具byebug来了。虽然byebug也能调试Rails应用,但它不提供语法高亮,所以使用pry-byebug是个更好的选择。

Ruby 1.8+ Ruby 1.9 Ruby 1.9.2+ Ruby 2+
Ruby ruby-debug ruby-debug19 debugger byebug
Rails pry-nav pry-nav pry-debugger pry-byebug

其它

Pry其实不是纯粹的调试工具,它只是IRB的替代品,所以缺乏必要的调试指令。pry-nav、pry-debugger和pry-byebug做的只是分别把ruby-debug、debugger和byebug中的step、next、continue等指令添加到Pry中。

  • pry-nav = Pry + ruby-debug
  • pry-debugger = Pry + debugger
  • pry-byebug = Pry + byebug

如果要调试view怎么办?可以使用Web Console。在view里面加上<%= console %>,当view出现异常时,就会在异常界面下方,出现一个网页版的IRB,方便调试。Web Console默认只接受localhost的请求,假如需要让别的IP也能访问的话,可以这样做:

1
2
3
class Application < Rails::Application
  config.web_console.whitelisted_ips = '192.168.0.100'
end

如何使用VisualVM检测Java内存泄漏

Java的一个重要优点是通过垃圾收集器(Garbage Collection)自动管理内存的回收,程序员不需要关注它。程序员真的不需要关注内存管理吗?只要你碰到过OutOfMemoryError你就知道它不是真的。

这里我会展示如何使用VisualVM快速定位内存泄漏。先看下面这段代码:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
import java.util.List;
import java.util.ArrayList;

public class MemoryLeakDemo {
    public static void main(String[] args) {
        new Thread(new MemoryLeak(), "MemoryLeak").start();
    }
}

class MemoryLeak implements Runnable {
    public static List<Integer> leakList = new ArrayList<Integer>();

    public void run() {
        int count = 0;
        while (true) {
            try {
                Thread.sleep(3);
            } catch (InterruptedException e) {
            }
            count++;
            Integer i = new Integer(count);
            leakList.add(i);
        }
    }
}

执行下列命令:

1
java -verbose:gc -XX:+PrintGCDetails -Xmx20m MemoryLeakDemo

等待一段时间后,你会看到:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Exception in thread "MemoryLeak" java.lang.OutOfMemoryError: Java heap space
        at java.util.Arrays.copyOf(Arrays.java:3181)
        at java.util.ArrayList.grow(ArrayList.java:261)
        at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)
        at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
        at java.util.ArrayList.add(ArrayList.java:458)
        at MemoryLeak.run(MemoryLeakDemo.java:22)
        at java.lang.Thread.run(Thread.java:745)
Heap
 PSYoungGen      total 3584K, used 298K [0x00000000ff980000, 0x00000000ffe80000, 0x0000000100000000)
  eden space 3072K, 9% used [0x00000000ff980000,0x00000000ff9ca908,0x00000000ffc80000)
  from space 512K, 0% used [0x00000000ffc80000,0x00000000ffc80000,0x00000000ffd00000)
  to   space 512K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000ffe80000)
 ParOldGen       total 13824K, used 12156K [0x00000000fec00000, 0x00000000ff980000, 0x00000000ff980000)
  object space 13824K, 87% used [0x00000000fec00000,0x00000000ff7df3e8,0x00000000ff980000)
 Metaspace       used 7993K, capacity 8164K, committed 8448K, reserved 1056768K
  class space    used 912K, capacity 954K, committed 1024K, reserved 1048576K

打开VisualVM开始监测MemoryLeakDemo,在Monitor标签页我们可以看到实时的程序内存堆的使用情况:

波峰到波谷处是执行了GC的,明显可以看到执行GC后内存曲线仍旧呈上扬趋势,也就是说,内存占用是只升不降。到底是什么原因导致的呢?

打开Sampler标签页,点击Memory按钮启动一个内存分析会话,VisualVM会定期获取所有执行线程的转储,分析栈跟踪信息,实时显示成堆直方图。通过堆直方图,我们就可以知道哪个对象占用了较多的内存,以便做进一步的优化。

如上图所示,第1行的Integer对象占用内存最大,已经有41万多实例了,并且还在持续增加中。很显然,罪魁祸首就是它了!

对抗完美

英文原文:http://usabilitypost.com/2008/10/08/fighting-perfection/

如果你像我一样,你可能经常会发现自己从来没有完全满意你的工作——总是做出调整和修改,总是找到你不太喜欢的事情然后改进它们。这适用于很多创造性的努力——或许你正在为你的博客加工一篇文章,整理一份报告或者写一封重要的电子邮件。

问题是,即使在作出修改后,仍然有一些事情你可以调整,事情仍然不是相当完美。

这当然是很好的,你给自己设置了一个高标准。如果你不满意你的工作,那么为什么你的访客或客户就要满意呢?

追求完美是件好事

一个建筑师拥有的两个最重要的工具是绘图室的橡皮擦和工地的大铁锤。

Frank Lloyd Wright

Steve Jobs不满意iPhone的第一个版本。他做了一个艰难的决定去放弃最初的设计,因为他不喜欢它;他觉得这不是Apple能做到的最好的。这给开发团队造成了很多问题,因为他们必须在很短的时间范围内整理出一份全新的设计。

新版本获得了成功,要是他没有做出这个艰难的决定,iPhone将不会成为手机行业的大标志,这在一定程度上要归功于它的标志性设计。

但是……

完美是困难的和费时的

完美可以是危险的和误导的。什么时候足够好?什么时候你可以前进,释放你应用的新版本或发布你的新文章?完美是太高的一个目标,因为它简直太难和太费时去实现。

如果你成了完美的奴隶,你会发现你所有的时间被耗尽。你会不停地做修改调整调整修改——事情却没有按时做完。

如何对抗完美?

考虑优先级——什么是真正要紧的事?对于一个非常大的公司,类似iPhone的东西是一个关键的产品;如果你搞砸了,它能造成严重损失。把产品做正确是至关重要的。设定一个非常高的标准在这里将是一个不错的主意。

那么更小的事情像是博客的设计呢?最终,它通常并不重要,除非这个博客是你的主要业务。在这里简单是你的盟友。简单的东西很难被搞砸,因此创建简单的事情然后把工作做完。

你最宝贵的资源是你的时间。为了对抗完美你必须将时间排出优先次序,并专注于那些要紧的事情。如果你正在做的和改进的事情没有那么重要,那么这些事情就不应该去做。

把事情做完

做完。开始把它当作一个咒语。当你去做完它时意味着某些事情已经被完成。决定已经做出,你可以继续前进。做完意味着你正在累积动力。

37signals, Getting Real

执行比想法更重要。把足够好的东西释放出来比做完美但从未完成的东西更好。不要在你做的每件事情上寻求完美——除了那些真正要紧的事情。驯服完美——更快地做完其它的每件事情,把节省下来的时间用在你最重要的项目上。

你能真正地掌握多少编程技术?

英文原文:http://thecodist.com/article/how-many-programming-technologies-can-you-really-master

我总是看见公司或者招聘人员广告他们正在寻找的人:“有从零开始开发iOS和Android应用的丰富经验,必须掌握现代移动和Web技术,包括Java、HTML5、CSS3、JavaScript、JSON和AJAX”。

没有这样的人。你可以掌握一门技术但在其它方面平平;你可以掌握一门技术然后转向另一门技术但是会忘记很多先前的技术;你可以简单地欺骗足够多的人让他们认为你能做到,然后期望你恰巧能够搞定它。

在今天,任何主要领域的编程都是高度复杂的,不断变化的,并且通常是带着很大时间压力完成的。所有这些都不允许你投入大量非编程时间去学习即使是最新的变化,更不用说从零开始掌握一切。你只能通过做真实的项目了解新环境,有多少人能够在同一时间同时编写所有大型的本地Android、本地iOS和响应式Web客户端呢?

在我作为程序员的34年里,我很少工作在超过一个主要领域。我的第一份工作是在一台supermini上,然后Apple上的6502汇编和在一台PC上的Pascal,我的两个创业公司都是用C为Mac开发,我更多地为其他人(包括Apple)工作,用C为Mac开发,一点点C++,接着从Objective-C/WebObjects转换到用Java开发Web客户端和服务端(尽管两者都很少),一些JavaScript,然后在Mac和Windows上进行C++游戏编程,最后是Objective-C和iOS。每次转换都是匆匆忙忙地大量学习,接着是年复一年的掌握所有新的东西。

如果由于某种原因,有人确实能做Android和iOS两者——更不用说Web——以一个真正的大师水平,他们应该能赚比大多数公司愿意支付的更多的钱。公司想要的是雇几个能做所有事情的人,并且以他们能够得到的最低的工资水平。然而我无法理解有人能够同时在这么多事情上成为一个专家,以及他们如何能够用多种技术编写多个应用并且坚持下去。我认识一些极其聪明的人,但我不记得有人棒到确实能在同一时间兼顾不相关的技术并且产出技艺精湛的应用。

也许会有例外。但我仍然认为大多数人做不到。人们当然可以掌握一件事情然后转向掌握另一件事情,但在这个过程中你不可避免地会忘记前者的细节。去年,我在等待裁员且没有什么事情要做的几个月里(我是最后无缘无故裁员中的一个,因为在品牌的最终出售之前我们所有的技术已经被换掉了),我花了一个月的时间在C++上,然后Node.js,最后Swift。今年继续这些语言(因为我的新工作做的是Objective-C)我发现我已经忘了大部分我所学过的。如果你不经常使用某样东西,记忆似乎丢到了脑后。在用PHP重写这个博客引擎的过程中我在我脑中把所有这些语言都搞混了。

如果你是在iOS上从Objective-C转到Swift,那至少还有些重叠。但Android和iOS不仅是不同的语言,一切都不同,从工具到如何布局去支持多个主要的OS发行和24,000多种不同的设备。仅仅是跟上所有这些年在六月WWDC的新变化就要花费大量的精力;雪上加霜的是Apple释放的示例代码在最新beta版的XCode里已经不能编译。就算你不写代码整天只是观看视频和阅读文档与示例代码,你怎么能一本正经的说你是一个专家呢?

给两个不同的移动OS环境添加复杂混乱的是现代Web开发,特别是那些某一天出现然后第二天消失的JavaScript框架。你需要三个脑袋才能跟上它。和我一起工作的JavaScript程序员也就够跟上一个(在这里是AngularJS)。

因此找一个能用JavaScript写iOS、Android和移动/桌面Web的人,使用现代的API并且仍然可以支持旧的OS版本,明白不同设计和UI方法的优缺点,特别是所有不同浏览器和Android设备中的微妙之处,并且在创纪录的时间内交付无bug的结果,是幻想。哦对,还要以低于市场的价格为你工作。

当我开始编程时,一切都极其原始,我只需要知道一门语言和一种OS,根本没有框架。甚至在我的两个创业公司里我只需要掌握C,通晓Macintosh和一些偶尔的68K汇编。今时不同以往。然而我们仍然只有一个大脑,并且大脑不服从摩尔定律,它们不能升级。

因此,如果你能(诚实地)同时做Android、iOS和移动Web,并且交付技艺精湛的结果,我向您致敬!但我真的希望你也能赚3倍的钱。