V2EX Chris_Ys 的所有回复第 1 页 / 共 5 页

V2EX = way to explore

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

已注册用户请登录

1 2 3 4 5

2012-07-17 04:01:29 +08:00

回复了 lingyired 创建的主题 Javascript 有谁能告诉我Javascript 中的单引号和双引号有什么区别。。

推荐单引号，这样在大部分场合都能保持统一的风格且不影响阅读：

<div Onclick="alert('donot_do_this');">
html = '<div data-text="space works">'
document.querySelector('[data-text="space works"]')

在前公司的时候讨论过这个问题，貌似传统后端（如 PHPer）倾向于双引号，理由是有安全问题，国外那位 CTO 大叔也是这么想的，具体细节忘了。

2012-07-14 21:38:57 +08:00

回复了 kook 创建的主题奇思妙想寻找这样一款笔记软件

@nonozone
@kook desktop 没有分离线还是在线，iOS 则有分，付费才能完全离线，Android 似乎也没分（虽然官方说 Android 和 iOS 的离线受付费与否影响）。

2012-07-14 00:19:51 +08:00

回复 judezhan 创建的主题程序员话说V2EX的404不够geek啊...有同感么？

@feiandxs 搜索引擎看的是 header 的里 status code，只要是 404 就足够友好，你页面有什么内容它也不太感兴趣。

而「有爱的404页面」并不是针对搜索引擎，是针对「人类」:「Not Found」到底意味着什么找不到，「404」是什么暗号，对于没学过的人是不知道的，这类人群是最多的，甚至有不懂英文的。

再退一步，假设每个人都知道 404 是什么，但是在页面点了一个链接后，发现 404 了，有些人或许会想「你妹的！不存在就移除链接啊！」，特别是因为链接文字而点进来的，期待落空的不满会更大。这时候一个「好玩」的 404 页面就成了缓冲剂，不管是让人惊讶的还是有趣的，都缓解了用户的不满。

不过 v2ex 的定位而言，不懂 404 的极少（甚至没有），也可以忽略就是。

2012-07-13 03:20:06 +08:00

回复了 tuoxie007 创建的主题 App Store 这么好用的iOS浏览器不让上架，就因为和iPhone桌面长的太像

@Muninn 没研究过，互通消息并不太清楚，只见过 Facebook 有类似的行为：一个 App 请求验证时打开 Facebook 的 App，验证完毕回去请求方 App。由于次数少得可怜，我只记得打开的不是 Safari，所以觉得应该是 Facebook.app。

Mac 经典产品 TextExpander 也有对应的方法供别的应用实现补全，由于我没使用过（没购买），所以不敢断定，感觉 iOS 里的应用即使能互通消息，也是比较难的。

这点没有 Android 自由，但也不算不上「封闭」，因为苹果给出的理由和动机的很充分：安全，也因此带出了 sandbox 机制，这个机制很大程度地影响程序互通。

不过自由的 Android 倒是很微妙，不仅国内的应用商店爆出带毒的新闻，Chrome Web Store 也有众多玩小动作、滥用权限的插件，比如 Proxy Switchy Plus 的汉化版。

这样一看，不管是哪种做法，都是双刃剑。不过苹果的审核机制结合 Google 的开放式 API，倒可能是最理想的。

2012-07-12 17:19:17 +08:00

回复了 tuoxie007 创建的主题 App Store 这么好用的iOS浏览器不让上架，就因为和iPhone桌面长的太像

@Muninn 估计 Chrome for Android 不会引入目前的插件机制，一方面信息比较敏感，一方面资源有限：

1. desktop 的插件可以使用 dll 等文件，做成病毒的话，非常危险，手机也不同于电脑，信息更敏感
2. 目前一个小小的插件内存消耗基本是 30MB 起步，并且是一直占用，直到浏览器或插件关闭。

由于移动端的资源非常有限（目前常见的最大容量是 1GB），而且一个 App 为了节省资源，即使是 Google 的程序也不会在后台保持着激活状态，也就是说，唤醒浏览器后，插件（很可能）需要重新激活，在性能和体验上也就不理想了。

个人倒是想看看 Google 能推出什么样的点子。海豚支持 Pocket 也是内置实现，并不是插件，所以没有这方面问题。

2012-07-12 05:14:58 +08:00

回复了 tuoxie007 创建的主题 App Store 这么好用的iOS浏览器不让上架，就因为和iPhone桌面长的太像

@jerry 在 iPhone 保存 bookmarklet 确实比较麻烦，Read it Later 时官方有一个很详细的教程，大概两至四步可以完成，勉强能接受，变成 Pocket 后不知道官方还没有保留著这个教程。

我个人还是比较少用 Safari 的 reading list，或者说除了试用之外没用过，我还是比较依赖 Chrome + extension & Safari + mail URL to Pocket/Readability/... 的方式，也幸好他们贴心地提供了这个功能。

2012-07-12 04:55:30 +08:00

回复了 tuoxie007 创建的主题 App Store 这么好用的iOS浏览器不让上架，就因为和iPhone桌面长的太像

@Muninn 另外你说的「封闭」不知道你怎么得出这个结论，首先，主流浏览器之中没有任何一家是内置第三方服务，Chrome 没有，Firefox 没有，甚至 Opera 也不例外。它们支持第三方服务的手段一般是：

1. 系统级插件（ActiveX）
2. 浏览器插件
3. Bookmarklet

1、2 两点，还没见过任何一家内置浏览器支持，即使是 Chrome for Android 也没有支持 extensions，其中的理由并不是「封闭」还是「开放」的问题。

而 bookmarklet，Safari mobile 也是能支持的，和 desktop 一样的方式。

如果按照你的观点，在内置级移动浏览器不支持第三方服务这点上，主流的（我知道的）都是「封闭」。

2012-07-12 04:49:30 +08:00

回复了 tuoxie007 创建的主题 App Store 这么好用的iOS浏览器不让上架，就因为和iPhone桌面长的太像

@jerry
@Muninn 早在 read it later 的时代，pocket 官方就提供了 bookmarklet，不过 reading list 不和 pocket 等同步是正常思维，毕竟 safari 自己就有 reader mode，ML 里也体现了这点：不管在哪，你都可以使用 safari 一致的 reader mode 体验。只是这里就有了一个很大很大的前提：用户长期能使用理想的网络。

2012-07-08 02:41:51 +08:00

回复了 Air_Mu 创建的主题问与答 XP里 IE8能降回IE6么？或者谁有装着IE6的 XP镜像。

@Air_Mu 试试 IE Collection。

微软有提供 XP 的镜像，只是使用时间有限。

2012-07-08 00:23:19 +08:00

回复了 ioloop 创建的主题 Apple macbook pro还是mac mini好？

@ioloop 如果是用 mini 的话强烈推荐入 trackpad，手势方面比起普通鼠标舒服。

2012-07-08 00:21:33 +08:00

回复了 loading 创建的主题 macOS PD里装xp还是win7

我 8GB 内存，装的是 win7，理由是 IE9+，XP 没戏，所以跳过。如果你的工作涉及前端，那就别想了，跑 7 吧。

两个虚拟机 8GB 还是够的，主要看你开的进程数，比如无节制地开 Chrome tab。

2012-07-06 04:49:40 +08:00

回复了 iceseaboy 创建的主题程序员 pinboard你搞毛呢？

@gee 「改密码一般也不会当着别人的面改」，你旁边有人也是人前啊，用户的环境不安全不是开发者的过错，所以选 text 还是 password 属于「喜好问题」，而不是「必然问题」。

数据库存的当然是客户端传过来的 md5 字符串加 salt 再 hash 的结果啊，密码安全的基本尝试，这种做法给用户提供了两层保障：

1. 网站拥有者、开发者不会得到用户的明文密码
2. 即使黑客获取了数据库的记录，没有 salt 的算法也无法破译原始密码

2012-07-06 00:23:37 +08:00

回复了 iceseaboy 创建的主题程序员 pinboard你搞毛呢？

type=text 并没有问题，这里对安全就有两个方面：

1. 本机的读取
2. 传输过程的泄漏

第一点，你本机有木马怨不得别人，改密码一般也不会当着别人的面改，况且要取值，一句 JS 就能搞定，所以明文还是 type=password 也就没所谓了。

第二点，type=text 和 type=password 都是一样，不加密都是渣。

我自己写的 web app 在传送前都用 md5 hash 一边再发，这个时候 text 还是 password 无关重要。不过我还是用 password，习惯问题。

PS：有一项调查是，密码即使输错一个字，大部分人也会重新完整输入，所以 type=password 比较让人没信心，强迫症的可能会反复验证，type=text 就解决了这问题。

2012-07-01 12:02:19 +08:00

回复了 RagnarokStack 创建的主题 Z shell oh-my-zsh启动速度很慢

听说 fish 挺有名气，在非 Mac 平台的用户反馈下，不需要额外配置就能工作得很好，可以试试 http://ridiculousfish.com/shell/

2012-06-12 03:43:14 +08:00

回复了 Kai 创建的主题 MacBook Pro 关于 Retina MacBook Pro 上面的两个雷电接口，为什么呢？

主要是为了外设吧，比如 Thunderbolt to FireWire，用 FireWire 的人还是挺多的，一棒子干掉估计怨气很大。

也就是一个主要供显示器，一个给除显示器外的外设备用。

另外 Belkin 前几天才公布了一个 Thunderbolt 的 Dock，所以备两个也符合苹果的想法。

2012-06-06 19:52:45 +08:00

回复了 arthur623 创建的主题问与答 Evernote,Wiz,Onenote,自建Wiki，你们选哪个管理笔记。不是开贴论战的，诚心求好的方案。

@arthur623 你可以用 GitHub 建 static page，再结合 Google 自定义搜索，完全免费还有快速安全的 hosting，本地也有一个备份以供离线阅读，所以这类 static HTML wiki 是挺多人用。

2012-06-06 18:58:59 +08:00

回复了 arthur623 创建的主题问与答 Evernote,Wiz,Onenote,自建Wiki，你们选哪个管理笔记。不是开贴论战的，诚心求好的方案。

既然标题说 Wiki 并且需要记 code，那 Evernote 等都是弱爆的。

第一个方案：Vim + vimwiki。

优点：

- 生成 HTML，带上 Dropbox 用浏览器一开就是一个简易 wiki。
- 支持 JS & CSS，代码高亮你懂的。
- wiki 语法的优点都有，比如 [page_name Page Title] 会自动维护链接，不怕改了后找不到。
- vimwiki 在 Win 下也可以正常跑，至少跨平台可行（要 Python）

缺点：

- 没有搜索。
- 没有导航。
- 没有结构良好的文章列表。
- HTML 模板的限制比较让人吐血。

第二个方案：markdoc

优点：

- markdown 语法支持。
- 有比 vimwiki 稍好的导航，
- HTML 模板比较强大。
- 自带本地 server。

缺点：

- 没有搜索。
- 没有结构良好的文章列表。

Mac 下可以用 Spotlight 和 Alfred 等工具，可以搜索内文，勉强补足不能搜索的缺点，别的缺点，暂时无解。

我个人在用 vimwiki，Evernote 是记「笔记」用，wiki 和笔记对代码来说的差别还是很大的，Evernote 还是弱了一点，除非，直接捕获 HTML 页面。

1 2 3 4 5