我的老 iPod Nano 命运多舛（ 一 、 二 ）。跌跌撞撞跟随我多年以后，其电池终于不行了，所以考虑更换。

拆机的过程 ifixit 上面都有攻略 ，所以很容易。工具和新的电池都是淘宝上购买的，感谢万能的淘宝。这里有个小插曲就是拆开以后，发现电路板上的焊点实在是太小，所以买了把新的电烙铁。

虽然是好几年前的产品，但拆开以后发现水果牌的硬件的确是没话说，电路板可以用艺术品来形容。据说有手艺好的更换了其存储芯片将其扩容，不过我个人觉得 2g 的容量塞 mp3 是已经足够了的。

新旧电池对比下。老的电池竟然只有 340 毫安，而且坚持了将近四年的时间，也算是寿终正寝了。新的电池估计是山寨的，淘宝上几十大洋搞定，也没有标号容量， 上帝保佑它不会出事 。

再次罗嗦一句，这板子上的焊点小的没法下手，技术不到家拆了旧的电池以后，新的电池就平焊焊了上去，反正它能工作了。惭愧，光顾着折腾，这个过程没有记录下来。

收工测试下，似乎目前一切正常，新的电池也能正常充电。充电时间明显变长，当然待机和播放时间也变长了，这小东西看来还能为我服役段时间。

总结下

• 工具很重要，来回这小东西让我在淘宝上买了两次拆机和焊接工具
• 拆机的时候注意用柔力，苹果的东西它可不会让你轻易拆开它
• 用电烙铁的时候注意接地，尤其是冬天身上的静电很多
• 就算是新电池估计也是库存了段时间的， 因此更换以后最好激活下
• 据说有容量更高的电池配件，不过如果打算更换的花还是考虑设备的实际情况，安全第一

-- EOF --

我们有时候会有这样的设想，能不能有款布局既兼容桌面浏览器，又兼容手持设备的小屏幕？ cssgrid.net 提供的方案 给与我们新的思路。

cssgrid.net 的秘密

这个站点自称这个布局为：

A 1140px wide, 12 column grid. Fluid all the way down to a mobile version.

细心的读者可能会发现，这句话其实会有冲突 -- 既然是流体布局，那么怎么限定了宽度呢？

拖动浏览器的窗口宽度，或者使用 iPhone 等设备访问该网站，发现布局会随着宽度的缩小发生改变，从而使页面的内容更容易阅读。它是如何实现的呢？

给力的 @media

如何给不同的设备载入不同的样式，有可能我们首先想到的就是 CSS Hack 。看其的 CSS 载入方式，我们或许就已经能明白个大概。 media 这个属性 这个时候就变得非常的给力。

<!-- The 1140px Grid --> 
<link rel="stylesheet" href="css/1140.css" type="text/css" media="screen" /> 

<!--[if lte IE 9]>
    <link rel="stylesheet" href="css/ie.css" type="text/css" media="screen" />
<![endif]--> 

<!-- Make minor type adjustments for 1024 monitors --> 
<link rel="stylesheet" href="css/smallerscreen.css" media="only screen and (max-width: 1023px)" /> 

<!-- Resets grid for mobile --> 
<link rel="stylesheet" href="css/mobile.css" media="handheld, only screen and (max-width: 767px)" /> 

上面的代码可以看出， 1140.css 是布局的主体 。然后，其针对 IE 单独提供了 ie.css，浏览器宽度（或者可以理解为屏幕宽度）为 1024 像素以下、768 像素以上使用 smallerscreen.css；小于 768 像素宽度的则使用 mobile.css。

根据上面定义的典型宽度不难看出，其实 smallerscreen.css 针对的是 iPad 等平板设备，而 mobile.css 针对的是 iPhone 以及 Android 等手机设备。

这是个 CSS 按需加载的好办法。还有个问题就是，可不可以将它们写到单个文件中，节省连接数也方便维护？当然可以。例如：

<!-- Resets grid for mobile --> 
<link rel="stylesheet" href="css/mobile.css" media="handheld, only screen and (max-width: 767px)" /> 

我们需要写到单个文件中，那么内容使用

@media handheld, only screen and (max-width: 767px) {
    /* ... */
}

包裹起来即可。

宽度的技巧

似乎有些偏题，回到正题我们继续分析 cssgrid.net 的布局。 继续查看 1140.css ，其实可以得知就是个浮动布局。有点不同的是 .row 的样式：

.row {
    width: 100%;
    max-width: 1140px;
}

这种写法当时让我眼前一亮。一般常见的写法是直接使用width:1140px。这样写法的好多多。例如，使用相对宽度、栅格的宽度也对应的使用百分比，那么总体的栅格该起来将会方便很多。

A：「那么 IE6 怎么办？」 B：「别闹了。」

顺便说一句，我们目前广泛采用的 960 栅格系统 是否可以考虑革新下。根据目前的用户屏幕分辨率数据（via 黑三 ）来看，桌面屏幕宽度大于等于 1024 像素的分辨率占到了绝大多数的比例。

我们可以考虑采用例子中 1140 像素或者更大宽度的栅格系统 -- 这将对于设计以及内容安排方面而言，也将会拥有更大的发挥空间。

One Size Fits All?

说到这里其实这个布局的大部分技术原理也了解了大概，其实如果不喜好浮动布局，了解了上述的原理以后，任何布局我们都可以通过重置样式的方式改进使其支持移动设备。

学习 CSS 的过程中总是会不可避免的会碰到布局的问题，同时这也是争论最多的部分。无论是浮动布局、定位布局、 「伪绝对定位布局」 、还是 「双飞翼布局」 等等，其实都是根据具体的情况而总结出来的布局。

所以，我个人的观点就是，其实没有任何应对各种情况的布局 :^)

那么，您的观点呢？

-- EOF --

项目中碰到 PHP 和数据库之间，计算存在时间计算误差。大致的情况为根据段时间字符串，例如

2012-12-14 00:00:00 UTC

使用 MySQL 的 UNIX_TIMESTAMP 函数以及 PHP 的 strtotime 计算得出的时间戳，大概有半分钟（差不多有28秒）的误差。

同时，比较‘诡异’的是直接使用当前时间（MySQL 中 UNIX_TIMESTAMP 不带参数，同时 PHP 直接使用 time 函数），却不存在误差（ 测试脚本 ）。

排除了 PHP 和 MySQL 之间因为时区设置造成的时间误差 -- 根据经验，如果是时区设置造成的时间误差，应该有几个小时不会那么少。

搜索解决问题期间扫了下 这篇帖子 ，觉得应该是 ‘闰秒’ 这玩意造成的问题。搜索 PHP 闰秒相关的配置似乎没有相关的， 不过在这里似乎找到了些答案 。

You also can experience this behavior if your system timezone
is with leap seconds. To avoid the problem in this case please
run query UPDATE mysql.time_zone SET Use_leap_seconds='N' 
and restart the server. Please inform us if this helps.

按照上述的步骤执行，解决了问题。

回过头来，我在工作机（Windows）上测试，发现并不起作用。研究了下， 原来闰秒也需要操作系统的支持 ：

1、对于大多数新的 Linux 内核，在设计时它们都是支持闰
   秒的，这一点在 REHL4/5 的 2.6.x 内核中得到肯定。 
2、如果 Linux 系统没有配种某种时间同步机制（比如NTP），
   那么和闰秒无关，唯一导致的结果只是系统时间会比 UTC
   时间快一秒。 
3、Window Time Service 不支持闰秒，包括服务器和客户端。

回过头来考虑项目中碰到的这种情况，直接使用时间戳存储时间点会更精确些。最后， 提供下相关的测试脚本 ，看看你的环境是否也会有类似的问题。

-- EOF --