V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  otakustay  ›  全部回复第 215 页 / 共 290 页
回复总数  5782
1 ... 211  212  213  214  215  216  217  218  219  220 ... 290  
真要拿走拍照都能拍走,这种管控实在是无聊
事实上 7 天假是太长了,而不是不够
频繁的小假才是比较合理的玩法
2015-12-08 16:25:07 +08:00
回复了 JohnLou 创建的主题 问与答 这几天面试了几个前端,说说感受
老实说 vertical-align 我也搞不清,少数搞不清的 css property 了……
2015-12-08 13:22:07 +08:00
回复了 GhostEX 创建的主题 问与答 码农眼疲劳怎么办?用什么缓解视力下降
去医院检查一下,有可能是视网膜易脱落的体质,我就是这样……
2015-12-07 17:17:11 +08:00
回复了 otakustay 创建的主题 ACG 发布个小应用 - 小薄本
@godonlyknows 普通漫画和小本子有很大不同就在你说的这些了,我是打算慢慢加,只有双页模式对设计调整蛮大的,其他还好办
以后我还打算加个文件 tag 管理,总是会某天特别想看某一类的……
2015-12-07 16:41:41 +08:00
回复了 otakustay 创建的主题 ACG 发布个小应用 - 小薄本
@Elix 享受 30 寸显示器的快感啊!


@wjchen 这真没办法,作为一个 FE ,不让我用 electron 我就只会写 WPF 了……
2015-12-07 16:28:44 +08:00
回复了 otakustay 创建的主题 ACG 发布个小应用 - 小薄本
@godonlyknows Simple Comic 曾经也是我的选择之一,但最后我放弃了,主要是这样的

Image scaling: Original size, window fit and horizontal fit

这是 Simple Comic 支持的缩放模式(在我的应用中叫做布局),但事实上实际看本子的时候,这 2 种都不行:

1. original size 的话,本子很多是 4K 级别以上的图片,根本不可能简单地用键盘进行导航,同时这么大也没必要,一屏幕还显示不了几个部位
2. window fit 会导致图片太小,因为多数本子的图片是纵向远大于横向的,做 window fit 就是很细的一条, 23 寸及以下的显示器上对话都可能看不清
3. horizontal fit 又太大,本子的图片纵横比在 1:3 以上, horizontal fit 意味着要滚 3 次屏,本子要的是快餐式消费,不会地看这么精细

另外 Simple Comic 无论哪种 scaling ,都没有 step 的概念,即我按个键进到下一步而不是直接换下张图,这就导致 Simple Comic 还是需要 touch pad 或者鼠标进行图片的移动,这在只有一只手可用的情况下是比较折腾人的

所以其实我去做这个应用,出于自己的习惯,主要的目标就是全键盘和只要一个按键就能一路读到底的模式……
2015-12-07 15:18:52 +08:00
回复了 otakustay 创建的主题 ACG 发布个小应用 - 小薄本
@kumakiti 都是 north-plus 里弄来了,请自行搜索……你可以写个爬虫,到时候分享下嘛
2015-12-04 15:02:17 +08:00
回复了 ben548 创建的主题 硬件 sky 的钛度鼠标,只能呵呵了
@ben548 现在部分情况是用其它设备统计的,比如 APM 游戏自带统计,这些集成到鼠标里对电竞人士来说总体是有益的
我们普通玩家就别掺和这些了……
2015-12-04 13:48:17 +08:00
回复了 ben548 创建的主题 硬件 sky 的钛度鼠标,只能呵呵了
人家鼠标的目标就是向职业走的玩家,没个 APP 统计怎么成长,靠脑补么……
2015-12-04 13:14:52 +08:00
回复了 wangccddaa 创建的主题 Swift swift 开源了,大家怎么看
@otakustay C#也能 PInvoke 性能还不低,但这其实真的没啥用,因为不同语言的“哲学”不同,混用在一起只会让人难受到放弃,所以关键还是在于支持非 Client 开发对应的组件是否成熟……
2015-12-04 11:40:02 +08:00
回复了 wangccddaa 创建的主题 Swift swift 开源了,大家怎么看
关键还是看有没有足够的库和运行时支持,光语言的话我为啥不选 C#
2015-12-03 15:04:21 +08:00
回复了 Gem 创建的主题 JavaScript 现在,写 JS 带不带分号?
@learnshare 我完全不明白不加分号会产生什么问题,是人会看不懂还是机器会看不懂……
2015-12-03 14:12:10 +08:00
回复了 Gem 创建的主题 JavaScript 现在,写 JS 带不带分号?
发错, airbnb 是以分号为主流的,找错

顺便再给一个调查: https://twitter.com/JavaScriptDaily/status/662655515500089344
2015-12-03 14:11:00 +08:00
回复了 Gem 创建的主题 JavaScript 现在,写 JS 带不带分号?
@FrankFang128 规范还是得写明白,事实上没多少人知道什么是“必要的时候”,不如拿这个当面试题坑人去


@learnshare 哪来的共识,随便给你找几个:

airbnb : https://github.com/airbnb/javascript#semicolons
github (虽然是以 coffee 为主): https://github.com/styleguide/javascript

虽然现在确实加分号是主流,但还没到“共识”这个程度,不加分号是可以运行得好好的
2015-12-03 13:30:54 +08:00
回复了 Gem 创建的主题 JavaScript 现在,写 JS 带不带分号?
上面有点说错,不是对象字面量里遇到 Computed Property Key ,是在 Decorator 撞上一个 Computed Property Key 的时候

大部分情况下是没关系的,只有下一条语句是以[或者(起始的时候,上面才必须分号结束,但这种语句太少太少
2015-12-03 13:27:48 +08:00
回复了 Gem 创建的主题 JavaScript 现在,写 JS 带不带分号?
最近在着手做公司的编码规范, ES6 如果使用全带分号的写法的话,在 ES7 的 Decorator 上会遇上不小麻烦
如果选全不带分号的话,在对象字面量里遇到 Computed Property Key 的时候会遇上些麻烦

所以简单来说就是, ES 垃圾!
2015-12-01 18:59:32 +08:00
回复了 qw7692336 创建的主题 问与答 用什么语言解算法题最爽?
这种时候一般不是 R 或者 Haskell 吗
2015-12-01 12:14:36 +08:00
回复了 ouyangzetao 创建的主题 问与答 为什么前端,非要懂后端程序架构?
估计要你直接产出 Razor 模板了吧
1 ... 211  212  213  214  215  216  217  218  219  220 ... 290  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1140 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 58ms · UTC 23:23 · PVG 07:23 · LAX 16:23 · JFK 19:23
Developed with CodeLauncher
♥ Do have faith in what you're doing.