首页   注册   登录
 secondwtq 最近的时间轴更新
secondwtq's repos on GitHub
HTML · 1 人关注
Ares_Ex1
A small extended version of Ares Yuri's Revenge Extension.
OCaml · 1 人关注
cfp
CSS · 1 人关注
hacking_into_iTunes
[Web] Music metadata search page with iTunes API.
0 人关注
7Tsh
A Test Shell.
0 人关注
awesome-compiler
A curated? list of awesome compiler-related projects, tutorials and courses.
TypeScript · 0 人关注
binpacker
React sprite packer (for games, etc.)
OCaml · 0 人关注
bmon
Watch and download specified live stream channel of bilibili. (Strictly Linux ONLY!)
TypeScript · 0 人关注
DefinitelyTyped
The repository for high quality TypeScript type definitions.
Emacs Lisp · 0 人关注
doom-emacs
An Emacs configuration for the stubborn martian vimmer
Shell · 0 人关注
dotfiles
JavaScript · 0 人关注
ease
slEep As a SErvice.
C++ · 0 人关注
einstein
HTML · 0 人关注
expressus
JavaScript · 0 人关注
exturl
TypeScript · 0 人关注
fullslide
C++ · 0 人关注
HOWARD11
0 人关注
HOWARDAssets
C++ · 0 人关注
IllybLauncher
C++ · 0 人关注
IllybLauncherRocket
0 人关注
Interfacer
C++ · 0 人关注
Kaleidoscope
Lua · 0 人关注
luajit-lang-toolkit
A Lua bytecode compiler written in Lua itself for didactic purposes or for new language implementations
Haskell · 0 人关注
marskow
C++ · 0 人关注
MarXsCube
Project MarXsCube. A 2(.5)D game engine (mainly for RTS) with (a small) C++ Core and (modified) Lua for extension.
JavaScript · 0 人关注
Meow
A Web Simple Collaboration Markdown Editor
Go · 0 人关注
miniflux
Minimalist feed reader written in Go and Postgresql, with my customizations.
0 人关注
mirage
OCaml · 0 人关注
mmp
Emacs Lisp · 0 人关注
mojimacs
Python · 0 人关注
mopidy-qobuz

secondwtq

V2EX 第 81805 号会员,加入于 2014-11-16 03:41:33 +08:00
又到了让诸位 V 友做人生导师的时候了,关于要不要读研。
职场话题  •  secondwtq  •  2017-04-22 13:39:18 PM  •  最后回复来自 cpygui
79
请教几个关于订票网站的设计问题
问与答  •  secondwtq  •  2016-01-05 15:22:59 PM
日经一下, Google 首页改版了?
分享发现  •  secondwtq  •  2015-09-03 00:18:11 AM  •  最后回复来自 acess
29
求推荐一款适合折腾的无线路由器
问与答  •  secondwtq  •  2015-05-16 09:32:34 AM  •  最后回复来自 Dreista
14
secondwtq 最近回复了
6 小时 1 分钟前
回复了 nasmatic 创建的主题 奇思妙想 刚看了两个近义词不同释义的感悟
@nasmatic 你需要看大量的 hinative,wordreference 和 stackexchange 才能有初步的理解,并且不同人给你的解释不一样。就别说 hinative,wordreference 和 stackexchange 也有大量对词典的引用,也就是说很多”本地人“在解释的时候也出现了主楼所说的”说不清道不明但你又很难用错“的情况,而这个时候最普遍的 fallback 是词典。
相比来说,词典(主要指英英词典)在极小的篇幅中压缩了极大的内容(这也是词典本身的目的所在),只是读者能不能理解的问题
(你以为英英词典就不是本地人写的了 ...

原因就是词典就是对语言在应用中的经验再总结沉淀为理论的产物,相比于经验来说是更加 higher order 的东西。hinative,wordreference 和 stackexchange 上这类问题的大牛的终极形态是一本人肉词典 ...
7 小时 0 分钟前
回复了 nasmatic 创建的主题 奇思妙想 刚看了两个近义词不同释义的感悟
我来 generalize 一下楼主的”感悟“:
很多你以为的”技术问题“其实不是”技术问题“而是”经验问题“

扩展:人们是尊重经验的,但我觉得人们更偏向于能把经验抽象为理论(也就是沉淀到”技术问题“)

就楼主的这个近义词问题来讲,我觉得目前词典是做得最好的
8 小时 11 分钟前
回复了 iRiven 创建的主题 分享发现 那些寻找小屏手机的点击来看看,也许对你有帮助
楼主这个统计的精神可嘉,但是干不过小屏手机在市场(尤其是 Android )事实上已死的现状
就像我也有个类似的 CPU/GPU 统计,统计的结果是没一个能买的(嘛,大概 2191B 除外 ...)

”小屏“当然就是指”小屏“啦,不是指正面面积小,是屏幕面积小,正面面积小但是屏幕面积不够小照样没法单手操作(主要是屏幕太长)
”正面面积小但是屏幕面积不够小“(或者”年前对于小屏手机的定义是 5 寸,而 2019 年,把 6 寸以下手机定义为小屏机“)的原因是”全面屏“的普及。但是这个”全面屏“怎么做可大有门道
Apple 把 iPhone 8 的屏幕尺寸不变,额头和下巴切掉再加个刘海算是”全面屏“,Apple 把 iPhone 8 的整机尺寸不变,屏幕放大再加个刘海也是”全面屏“。但是前者还依然能算是”小屏“,后者就不那么”小屏“。(事实是不仅 Apple 走了后者,”全面屏“后的 iPhone 长宽高甚至都又大了一圈 ...)
”全面屏“之前的很多手机在屏幕左右的边框上已经做得很窄了,”全面屏“概念上主要是消除上下的边框(实现中是通过放大屏幕来消除边框),但是对于”小屏“来说,上下边框有多宽其实根本无所谓,他整个 3 cm 的下巴照样是小屏。
14 小时 33 分钟前
回复了 coolworker 创建的主题 生活 逃避现实的一百种方式
你的第二行其实可以归到第一行里面 ...(前提是你在做第二行时没有消费行为)
现实就是 996,以及 996 升级到 007,你只要没有在为社会主义现代化建设做贡献,你就是在逃避现实。
14 小时 45 分钟前
回复了 kidlj 创建的主题 随想 人类真的太棒了!
和楼主不同,我认为人类作为一个物种,最伟大的地方体现在这个网站以及它所提出的设想:

http://www.vhemt.org/success.htm

> We’re the only species evolved enough to consciously go extinct for the good of all life, or which needs to. Success would be humanity’s crowning achievement.

> May we live long and die out.
14 小时 53 分钟前
回复了 vinHty 创建的主题 问与答 询问一个版本管理的问题
这个硬件厂商玩了好多年了已经 ...
有空多看看 AI 界和医学界大佬 Jensen Huang 的演讲,买买他出的书和课程,支持一下他的燃气灶业务
14 小时 56 分钟前
回复了 okwork 创建的主题 iDev APP store 即将限制 h5 混合应用,苹果会全面支持 pwa 吗?
当然有替用户考虑的成分,Web 技术本来就不适合开发应用,大多数基于 Web 的应用的效果也就那样。禁止了 Web 技术在应用中的滥用,用户的使用体验更好了,续航更长了。
也当然有替开发者考虑的成分,对 Web 技术的限制会增加对 Apple 平台原生开发者的需求,Apple 护自家开发者的犊子,消灭投靠 Web 的异教徒可以理解。

但是我不看好这种用简单的技术手段解决非技术问题的尝试。
iOS vs. Android 的根源其实是个千年老问题:管理者该管多少合适?“自由”的边界在哪里?
@murmur 我的理解,Apple 此举的主要目的,通俗地说就是禁止热更新(应用送审后行为不能改变,或者说与外界通信内容仅限于数据,不能传输程序)。
还有一种可能是遏止非原生框架(包括“H5“)的大量使用对体验的劣化,不过我个人偏向于前者。
所以理想情况应该是封有热更新行为的应用,但如 #48 所说这并不现实。之所以单独拎出”H5”,以及专门扯了一堆 WebKit JavaScriptCore 之类的,是因为使用“H5”和热更新这两者之间有一种奇妙的强关联,基本一抓一个准很少有错的,事实上就官方声明来看已经对“H5“采取了一刀切的手段。

但是我不认为所有类似的跨平台框架都在 Apple 的目标之内,因为”跨平台”和”热更新”根本就是两个正交的需求(虽然可以用同样的技术手段解决)。跨平台框架可以不做热更新。并且理论上,跨平台框架也可以做到把所有东西塞到一个 binary 里面(只是目前可能还很少这么做),至少可以满足技术上的要求(不运行 binary 以外的代码)。
“热更新”(或者广义上的执行非自身 binary 中的代码)也不是禁了已有的框架等具体的技术就能禁的,因为“数据”和“程序”其实是无法区分的。甚至一个程序有没有“热更新”行为也很难界定。

最极端的情况是有实力也有需求的大厂自己造私有的跨平台 /热更新的框架。想到这最搞笑的是,如果真有人用这种方法绕过热更新限制,那就没法做 JIT 的现状和某些华而不实的大厂的真实水平来看,可能最后体验还不如 H5
关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1865 人在线   最高记录 5043   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.3 · 18ms · UTC 01:05 · PVG 09:05 · LAX 17:05 · JFK 20:05
♥ Do have faith in what you're doing.