首页 注册 登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  3dwelcome  ›  全部回复第 30 页 / 共 155 页
回复总数  3084
1 ... 26  27  28  29  30  31  32  33  34  35 ... 155  
❮ ❯
2022-02-23 16:16:04 +08:00
回复了 3dwelcome 创建的主题 › 程序员 › 关于 PNG 图片二次压缩，刚发现一件很有意思的事情。
@vicalloy 是的，就算膨胀后，也还是会比更小。

我的资源是 27 个 PNG 文件，在 PS 里直出，总共 104,325 字节。尝试用 ZIP 压缩，以失败告终。

写了一点打包代码，把 27 个 PNG 打包成一个 JS 文件，体积为 139,647 字节。

这时候用 zip 再次压缩，最终大小为 88,165 字节。
2022-02-23 15:23:32 +08:00
回复了 LeeReamond 创建的主题 › 问与答 › service worker 缓存网站的原理是什么？有什么潜在的缺陷？
@LeeReamond "其他的所有 js/css/图片全都是 0ms 内存缓存，感觉就是开启成功了啊"

正常 http 缓存，也是先内存加载的。内存没有才找磁盘加载。

至于过期时间，一般资源设置的时间，还是挺长的。
2022-02-23 15:09:50 +08:00
回复了 LeeReamond 创建的主题 › 问与答 › service worker 缓存网站的原理是什么？有什么潜在的缺陷？
在我眼里就是一个 http 代理。

大网站不用的原因，就是不想让你离线用吧。

我工具网站没用，是因为 HTML 页面频繁更新，每次都希望向服务器检测一下，看有没有最新数据。

只要不下载资源，返回 304 速度很快的，和 service worker 离线几乎没多大差别了。
2022-02-23 14:01:27 +08:00
回复了 mikewang 创建的主题 › Java › 从零开始写一个 JPEG 编码器需要学习哪些知识？
JPEG 编码需要转换到频域操作，完全没学过，从头开始还是挺繁琐的，概念和细节很多。

你不如和导师建议，把 JPEG 改成 PNG 编码器，反正都是邻居。

PNG 也就是 Huffman 套个马甲，那个简单多了。
2022-02-23 13:16:36 +08:00
回复了 garywill 创建的主题 › 分享发现 › 这终端清屏方式真是绝
哈哈，这脑洞够大，也是闲人一个。
2022-02-23 12:23:48 +08:00
回复了 lanlanye 创建的主题 › 程序员 › 关于软件设计的一些问题
K 线是一维的，解释不了宏观和微观，我就用二维图片来代替。

一张堆满细节的超高清图片，在普通的 1080p 显示器上全图显示，细节是自动被抹去的，所谓的下采样。

细节一直存在，但是你看不见，你也不在乎，代码缩放也是这个道理。

放到最大，函数能看见。缩到全图，就自动退化成一个点了。这时候所谓函数名，函数参数都都不重要，用指令包裹起来，我只要发布指令和命令，软件能正常运作，就足够了。
2022-02-23 11:53:53 +08:00
回复了 lanlanye 创建的主题 › 程序员 › 关于软件设计的一些问题
@FrankHB 我们说的都不是一回事，你是说哪一种代码实现方法更好，可我说的是整体设计方向。

一个是低维，一个是高维，两者没办法放一起对比的。

你细节 API 代码只要花时间，最后怎么都能写好。但是管理海量代码，是需要一点技巧和模式的。
2022-02-23 11:50:27 +08:00
回复了 lanlanye 创建的主题 › 程序员 › 关于软件设计的一些问题
@liuhan907 "为什么你会认为指令比函数更容易维护？"

你要管理一整套基于函数的语法树，构建 AST 是相对复杂的。而程序化去提取指令，要简单太多。

你可能没接触过项目遗留屎山，就是函数和代码量多到，你怎么都改不过来。有时候并不是谁好谁坏的问题，是你看问题的角度不同，舍取的问题。

宏观对我来说，就是把函数细节抹掉，把精力省下来，留到更有意义的事情上。
2022-02-23 10:36:14 +08:00
回复了 lanlanye 创建的主题 › 程序员 › 关于软件设计的一些问题
@liuhan907 "何况大规模下几万个指令和几万个函数的理解成本没有什么区别。"

设计指令的目的，都是为了在不同维度下，让开发体验保证一致。

拿股票 K 线举例，你短线操作会观测到的细节，对于长线波段是没什么价值的，把细节抹去或者隐藏，才能让你更专注到更大的盘面，始终保持掌控力。

你封装函数，封装对象，同样也是为了隐藏细节。这帖子就是为了讨论宏观把控力，协程这些真的都是很枝末细节的部分。

海量函数能不能被很好的管理，要看开发者的经验。但指令模式，一定是可以用代码方式，科学维护管理的。
2022-02-22 23:37:55 +08:00
回复了 lanlanye 创建的主题 › 程序员 › 关于软件设计的一些问题
@Macolor21 以上古的 win32 编程举例吧。

一个 message ，就是一个 WM_USERREG 注册函数，加两个未命名的 wParam 和 lParam 。

没有函数体，不用给函数起名字。只需要 WM_USERREG 和若干个未命名参数，就可以执行一段用户注册的逻辑代码，并顺利返回结果。

反正就是这个意思。
2022-02-22 23:18:28 +08:00
回复了 lanlanye 创建的主题 › 程序员 › 关于软件设计的一些问题
@liuhan907 "你认为的指令和函数本质上的区别是什么 再增加一层抽象得到了什么好处呢？"

好处就是宏观写法和微观写法隔离开。

你管理几百个函数也许没问题，在几千上万个函数里跳来跳去，还是很有压力的。

我自己建立了一套指令网状体系，可以很快跳到自己需要修改业务的位置。
2022-02-22 23:15:14 +08:00
回复了 lanlanye 创建的主题 › 程序员 › 关于软件设计的一些问题
比如 Restful 的注册函数，正常写法，可能用户注册就是对应一个注册函数。

而我就是一个 RPC 的注册指令，和外部路由绑定后，就直接处理了。
2022-02-22 23:11:02 +08:00
回复了 lanlanye 创建的主题 › 程序员 › 关于软件设计的一些问题
@liuhan907 我这里的指令类似于 LUA 脚本定义，每个指令都是负责控制一堆函数体。是函数集的上层抽象。

函数里我一般不习惯牵涉业务，业务太多太杂，命名太辛苦，写一大堆函数没多大必要。而指令大部分都是能和业务实际挂钩的。

可能没代码很难理解，指令可以看成是 onmessage 里的一个个接受命令体，没有自己的函数入口，但能正常调用别的函数。但很可惜那个详细说明的帖子，我自己也找不回了。
2022-02-22 22:54:57 +08:00
回复了 lanlanye 创建的主题 › 程序员 › 关于软件设计的一些问题
我以前发了一个去函数编程的方案。

也就是用命令式指令，去替代传统函数的封装。类似一点 DSL 的定义。

可惜最后被移到了水深火热专区，因为大家都不信，去了函数后还怎么写代码。

这就是大家编程理念不同，微观上是函数，宏观上就自然升级到了指令。真是残念，我好多贴都去了水区，一去不复返。
2022-02-22 22:30:38 +08:00
回复了 liuguangxuan 创建的主题 › 编程 › 有老哥懂 mql4、5 这门语言吗？或者量化交易，有事情请教。
"3.国内做这方面的开发是否需要承担法律风险？"

说出来可能有点尴尬，国外合法的高频交易，到国内就变成了异常交易和市场操纵( https://zh.wikipedia.org/wiki/高频交易)
2022-02-22 22:19:50 +08:00
回复了 lanlanye 创建的主题 › 程序员 › 关于软件设计的一些问题
设计软件就炒股一样。股票里 K 线图有个著名的随机游走策略，导致你不管做短线，中线，还是长线，输赢概率是相同的。微观操盘和宏观操盘上，体验是一致的。

套用在软件开发也类似，从微观设计 API ，和宏观调用 API ，也需要保证开发体验是一致的，才能控制好全局。

不能因为代码增多，就陷入局部细节。要不断的封装对象，隐藏细节，让代码流程保持在一定可供总量。往往代码量太多，又没有合理的封装，才是屎山的开端。

至于“函数式编程的优势”，个人觉得就是能做到无状态编程，没内部状态维护，那么固定输入后，输出结果都是可预测的。能减少一些心智负担。
2022-02-22 21:26:49 +08:00
回复了 3country 创建的主题 › 职场话题 › 回看自己一年前职场困惑贴子有感
@dfkjgklfdjg “如果我上边说的 3 点都不能满足，或者说连起码的社保福利也不能满足你，那么你就得考虑问什么自己会出现这样的问题，只能选择这样的公司。”

有头部就有尾部，很多人就是一个很平凡的普通人，没想那么清晰的职业规划，就希望找个好公司，不加班，轻轻松松写点代码。

但这愿望放在一线大城市，是很难实现的，就因为行业很卷。理工科有能力的人并不少见，是真的要比隔壁文科卷的多。

如果有实力榜身，找工作也不迷茫。可迷茫又没实力的年轻人，才是主流和常态。
2022-02-22 21:04:56 +08:00
回复了 3dwelcome 创建的主题 › 问与答 › 既然 AI 算法那么厉害，为什么几乎没人使用 AI 压缩图片算法呢？
@stoneabc

所有的定义和使用场景，都是人为给予的。

对于计算机来说，就是 0 和 1 ，图片处理是定长压缩算法，还是变长压缩算法。

又或者是不是频域处理，一点都不重要。重要的是，ASTC 能很好的压图片，至少比 PNG 要好吧。
2022-02-22 18:43:40 +08:00
回复了 3dwelcome 创建的主题 › 问与答 › 既然 AI 算法那么厉害，为什么几乎没人使用 AI 压缩图片算法呢？
@Cmtter “这个模型怎么同时让全世界的设备（从手机，电脑，服务器到那些裸机设备）都能接受和支持并高效的跑起来是个很大的问题”

WASM 是万能的，速度也足够快了。
2022-02-22 18:41:33 +08:00
回复了 3dwelcome 创建的主题 › 问与答 › 既然 AI 算法那么厉害，为什么几乎没人使用 AI 压缩图片算法呢？
@LeeReamond 那就是每个人的认知问题不一样了。

我觉得 BC7/ASTC 这种，就是微软研究院智慧的结晶，人家也不可能凭空发明新图片格式，都是经过各种失败尝试后，成功的果实。

你网站里，一个解压后的图片是 JPG 还是 ASTC ，对用户来说完全是无感知的。更何况有 WASM 加持，一切解压算法，都能用 createObjectUrl 把图片变成一个 URL 地址。

既然算法能压游戏贴图，同样也能压网站流量图片。图片本质都是像素，木有区别。
1 ... 26  27  28  29  30  31  32  33  34  35 ... 155  
❮ ❯
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3283 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 42ms · UTC 12:02 · PVG 20:02 · LAX 04:02 · JFK 07:02
Developed with CodeLauncher
♥ Do have faith in what you're doing.