米米的博客

It's kind of painful to re-live this one. As a programmer, you learn to blame your code first, second, and third... and somewhere around 10,000th you blame the compiler. Well down the list after that, you blame the hardware.
回想起这个 bug，仍然让我感觉有些痛苦。作为一个程序员，在发现 bug 时，你学会了首先在自己代码中找问题，一次、两次、三次…… 或许在测试一万次之后，你会把问题归咎于编译器。只有在这所有的都不起作用之后，你才会把问题归咎于硬件。

This is my hardware bug story.
这是我遭遇硬件 bug 的故事。

Among other things, I wrote the memory card (load/save) code for Crash Bandicoot. For a swaggering game coder, this is like a walk in the park; I expected it would take a few days. I ended up debugging that code for six weeks. I did other stuff during that time, but I kept coming back to this bug -- a few hours every few days. It was agonizing.
抛开别的不说，我曾为古惑狼（Crash Bandicoot，PS1 游戏）写存储卡（读写）代码。对于一个自大的游戏程序员，这就像是在公园里散步一样轻松愉快；我预计只要几天就可以写完。我最终用了六个礼拜把那些代码调试完毕。在此期间我也做过一些其他的事情，但却一直绕不开这个 bug—— 每几天内就要花上好几个小时来处理。这个 bug 实在烦人。

The symptom was that you'd go to save your progress and it would access the memory card, and almost all the time, it worked normally... But every once in a while the write or read would time out... for no obvious reason. A short write would often corrupt the memory card. The player would go to save, and not only would we not save, we'd wipe their memory card. D'Oh.
这个 bug 的症状是，当你需要保存你的进度时，代码会访问存储卡，而大部分情况下没有什么问题… 但是偶尔读写会超时… 没有任何明显的原因。一个简短的写入经常毁掉存储卡。玩家要保存进度，我们不仅不保存，还擦除他们存储卡上的全部东西。天哪。

After a while, our producer at Sony, Connie Booth, began to panic. We obviously couldn't ship the game with that bug, and after six weeks I still had no clue what the problem was. Via Connie we put the word out to other PlayStation 1 developers -- had anybody seen anything like this? Nope. Absolutely nobody had any problems with the memory card system.
过了一段时间，我们在 Sony 的制作人 Connie Booth 慌了。我们显然不能发布带有这个 bug 游戏，而六个星期之后我对于问题出在哪一点线索都没有。通过 Connie 我们向其他 PS1 开发者求助：有没有人出现过像我们这样的情况？没有。绝对没有任何人在存储卡系统上出现任何问题。

About the only thing you can do when you run out of ideas debugging is divide and conquer: keep removing more and more of the errant program's code until you're left with something relatively small that still exhibits the problem. You keep carving parts away until the only stuff left is where the bug is.
在你绞尽脑汁之后，你能做的唯一一个调试方法就是分而治之：一点点去除错误程序中的代码，直到留下的代码相对很少，但仍然表现出问题。像雕刻一样去除没有问题的代码，留下的就是你的 bug 所在。

月下独酌
李白
花间一壶酒，独酌无相亲。
举杯邀明月，对影成三人。
月既不解饮，影徒随我身。
暂伴月将影，行乐须及春。
我歌月徘徊，我舞影零乱。
醒时同交欢，醉后各分散。
永结无情游，相期邈云汉。

八月十五夜月
杜甫
满月飞明镜，归心折大刀。
转蓬行地远，攀桂仰天高。
水路疑霜雪，林栖见羽毛。
此时瞻白兔，直欲数秋毫。

十五夜望月
王建
中庭地白树栖鸦，冷露无声湿桂花。
今夜月明人尽望，不知秋思落谁家！

南斋玩月
王昌龄
高卧南斋时，开帷月初吐。
清辉澹水木，演漾在窗户。
荏苒几盈虚，澄澄变今古。
美人清江畔，是夜越吟苦。
千里共如何，微风吹兰杜。

中秋月
苏轼
暮云收尽溢清寒，银汉无声转玉盘。
此生此夜不长好，明月明年何处看。

中秋月
齐已
空碧无云露湿衣，众星光外涌清规。
东林莫碍渐高势，四海正看当路时。
还许分明吟皓魄，肯教幽暗取丹枝。
可怜关夜婵娟影，正对五候残酒卮。

It's no great mystery that truly great user interfaces are the ones that are engineered to stay out of the way.
真正优秀的用户界面都是那些设计得「不挡路」的 —— 这并不是什么奥秘。
'Staying out of the way' means not distracting your users. Rather, good UIs let your users complete goals. The result? A reduction in training and support costs, and happier, satisfied and highly engaged users.
「不挡路」意味着不会分散用户的注意力。事实上，良好的用户界面可以让你的用户完成目标。结果呢？减少培训和支持的成本，以及让用户更快乐、更满意并被深深吸引。
Check out our other design courses at Treehouse.
在 Treehouse 查看我们的其他设计课程。
When getting started on a new interface, make sure to remember these fundamentals:
在开始设计新的用户界面时，请务必记住以下原则：

Know your user

了解你的用户

"Obsess over customers: when given the choice between obsessing over competitors or customers, always obsess over customers. Start with customers and work backward." -- Jeff Bezos
「对顾客的关注：当在关注竞争对手或顾客之间做出选择时，总是应该关注顾客。从顾客开始，用逆向思维工作。」 —— Jeff Bezos

Your user's goals are your goals, so learn them. Restate them, repeat them. Then, learn about your user's skills and experience, and what they need. Find out what interfaces they like and sit down and watch how they use them. Do not get carried away trying to keep up with the competition by mimicking trendy design styles or adding new features. By focusing on your user first, you will be able to create an interface that lets them achieve their goals.
你的用户的目标就是你的目标，因此请了解它们。重申它们，重复它们。然后，了解你的用户的技能和经验，以及他们需要什么。找出他们喜欢的界面，坐下来看看他们如何使用这些界面。不要试图通过模仿时尚的设计风格或添加新功能来跟上竞争对手，而忘乎所以。通过首先关注你的用户，你将能够创建一个让他们完成目标的界面。

Pay attention to patterns

注意 UI 样式

Users spend the majority of their time on interfaces other than your own (Facebook, MySpace, Blogger, Bank of America, school/university, news websites, etc). There is no need to reinvent the wheel. Those interfaces may solve some of the same problems that users perceive within the one you are creating. By using familiar UI patterns, you will help your users feel at home.
用户会将大部分时间花在除你以外的其他界面上（Facebook，MySpace，Blogger，美国银行，学校 / 大学，新闻网站等等）。没有必要重新发明轮子。这些接口可以解决用户在你正在创建的问题中感知的一些相同问题。通过使用熟悉的 UI 模式，你将让你的用户有宾至如归的感觉。

Stay consistent

保持一致性

"The more users' expectations prove right, the more they will feel in control of the system and the more they will like it." -- Jakob Nielson
「越多用户的期望被证明是正确的，他们对系统的控制感越强，他们就会越喜欢它。」 —— Jakob Nielson

Your users need consistency. They need to know that once they learn to do something, they will be able to do it again. Language, layout, and design are just a few interface elements that need consistency. A consistent interface enables your users to have a better understanding of how things will work, increasing their efficiency.
你的用户需要一致性。他们需要知道，一旦他们学会做某事，他们就能再次做到。语言、布局和设计只是需要一致性的一些界面元素。一致的界面使你的用户能够更好地了解事物的运作方式，从而提高效率。

JavaScript 函数有多种调用方式，每种方式的不同在于函数内 this 的初始化。对 this 关键字有解释：* 一般而言，在 JavaScript 中，this 指向函数执行时的当前对象。* 注意 this 是保留关键字，你不能修改 this 的值。

作为一个函数调用

先看一个最简单的实例，在浏览器中：

1
2
3
4

function myFunction() {
    return this;
}
alert(myFunction()); // [object Window]

而当函数没有被自身的对象调用时，this 的值就会变成全局对象。在 Web 浏览器中全局对象是浏览器窗口（window 对象）。该实例返回 this 的值是 window 对象。也就是此函数即为 window 对象的函数，myFunction() 等同于 window.myFunction()。但是此处在使用内部函数时存在一个 this 指向的问题，看下面的例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

// 注意此处在Node环境和浏览器环境下值不同,
// Node环境下必须去掉var使value成为全局变量。
value = 4;

var myObject = {
    value: 1,
    double: function() {
        //var that = this;
        var helper = function() {
            this.value = add(this.value, this.value);
        };
        helper();
    }
};

function add(a, b) {
  return a + b;
}

myObject.double();
alert(value); // 8
alert(myObject.value); // 1

在这里的 myObject 对象中，我们在 double 这个函数中使用了内部函数并赋值给 helper，但是此处的 this.value 的 this 指向了全局对象，所以在执行这个函数后全局变量 value 的值变了但 Object 中的 value 属性值仍然是 1，这不是我们想要的结果。《JavaScript 语言精粹》中指出这里是语言设计上的一个错误，this 应该仍然绑定到外部函数的 this 变量中。这个设计错误的后果就是方法不能利用内部函数来帮助它工作，因为内部函数的 this 被绑定了错误的值，所以不能共享该方法对对象的访问权。但是我们可以有一个很容易的解决方案去解决这个问题，对 myObject 进行修改：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var myObject = {
    value: 1,
    double: function() {
        var that = this;
        var helper = function() {
            that.value = add(that.value, that.value);
        };
        helper();
    }
};

myObject.double();
alert(value); // 4
alert(myObject.value); // 2

这里使用了一个 that 变量来指向 double 方法中 this 的值即 myObject 本身，这样就可以对 myObject 对象的属性 value 进行修改。

函数作为方法调用

这种方式即为，一个函数被保存为一个对象的属性，在此时此函数被成为一个方法。调用时 this 关键字被绑定到该对象，即：** 函数作为对象方法调用，会使得 this 的值成为对象本身。** 实例如下：

1
2
3
4
5
6
7
8

var myObject = {
    firstName: "John",
    lastName: "Doe",
    fullName: function() {
        return this.firstName + " " + this.lastName;
    }
}
myObject.fullName(); //返回 "John Doe"

另一个例子：

1
2
3
4
5
6
7
8
9
10
11
12

var myObject = {
    value: 0,
    increment: function (inc) {
        this.value += typeof inc === 'number' ? inc : 1;
    }
};

myObject.increment();
console.log(myObject.value); // 1

myObject.increment(2);
console.log(myObject.value); // 3

在此例中，increment 方法对 myObject 对象中的 value 属性进行增加操作，increment 函数中的 this 即指向 myObject 对象本身。

2018 年的暑期，诸多天文奇观轮番上演：火星冲日、日偏食、英仙座流星雨，这对天文爱好者来说是绝佳的观测机会。在好基友的怂恿下，笔者也正式踏入了天文摄影的巨坑。
笔者在小学时曾拥有一台 700/60 入门级伽利略式天文望远镜，但是其使用的经纬仪是纯手动的，调节精度较差；且望远镜本身存在明显的色差，成像效果不佳。为了满足行星摄影的要求，需要入手一台更为可靠的天文望远镜。目前市面上常见的天文望远镜，一般由三部分组成：三脚架（底座），赤道仪（经纬仪），以及望远镜镜筒。镜筒主体根据成像原理划分，有牛顿反射式、马克苏托夫 - 卡塞格林式和复消色差（APO）式等等。基于其他成像原理的望远镜也能在市面上买到，不过从销量和评价上来看，前文提到的这三种望远镜占主流。在查阅了大量资料，并参考了天文相关贴吧、论坛后，笔者决定入手信达小黑天文望远镜。这是一款入门级牛顿反射式望远镜，其焦距 750mm，口径 150mm，等效光圈较大，适合摄影；赤道仪采用 EQ3D，搭配双轴电跟，在通过北极星校准极轴后，即可进行长时间曝光。
这是望远镜组装完成的状态：

安装 EF 卡口转接环，就可以连接单反相机了：

8 月 11 日拍摄的日偏食：

由于望远镜自带的巴罗镜只适用于目镜，为了增加拍照的放大率，笔者还购买了一个 EF 卡口的增倍镜。这是使用增倍镜后拍摄的月球：

由于视宁度不佳（以及可能的对焦问题），虽然也成功拍摄了土星，但是土星环的辨识度较差：

仙后座（以及划过天空的飞机航行灯）：

本文更新于 2018 年 9 月 28 日：
与学校的青年天文爱好者协会部分（矿里有家的）前辈交流后，发现 EQ3D 赤道仪和双轴电跟仍有许多不足，可能并不是天文摄影的入门首选。如果有足够多的预算，可以购买 NEQ6 搭配 GOTO，该赤道仪的稳定性与鲁棒性都更胜一筹（当然价格也略高）。