V2EX › element90 的所有回复 › 第 1 页 / 共 2 页

V2EX = way to explore

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

现在注册

已注册用户请登录

1 2

❮

❯

60 天前

回复了 justincnn 创建的主题 › 互联网 › [help] 没有 docker 和网盘插件的 nas，有办法同步国内的网盘？

如果你的 nas 可以使用 shell 并且有权限的话，完全可以在 shell 中安装软件或者自行编写脚本解决你的问题。而且你都说了未下完就断开了，那应该是你已经可以这么做了。这个问题在非会员的网盘中经常出现，尤其是垃圾百度网盘，不但会断开，而且下载速度慢得离谱，需要你自行写逻辑续存

61 天前

回复了 kaesi0 创建的主题 › 服务器 › nodejs 后端项目如何部署？

我查了一下阿里云有直接容器云的服务，你索性就使用这种，用容器按需部署，这样既可以使用 serverless ，又不需要将每个服务接口单独构造 serverless 函数

61 天前

回复了 kaesi0 创建的主题 › 服务器 › nodejs 后端项目如何部署？

serverless 仅适合那些诸如体量小，任务独立，冷启动，时延要求低的服务，更准确来说是一个个独立且容易隔离的任务，这些任务每个都可以成为单独的脚本工程来维护，而不是一个大项目工程。如果你目前已经开发出一套服务，就没必要再次迁移到 serverless 了。

pm2 做负载均衡意味着你的服务是支持多进程无状态，所以可以在这个基础上挂个流量网关：nginx 或者 lb 服务配合一些脚本做弹性伸缩。

61 天前

回复了 emiharbur 创建的主题 › NAS › 求一个视频流可行的 nas 传输方案

我理解一下你的意思：你们由于 5~6 台计算机需要自行录制桌面（桌面监控），同时将录制进行中的文件使用 smb 协议传到黑群晖中备份供审计，但同时进行的话，每台计算机都会非常卡，且发现黑群晖性能占用率不高，带宽占用大概在 100M 。是这个意思吧？

如果是，那么意味着录制的过程中出现黑群晖文件写入瓶颈，所以即使几台独立的计算机在一起同时录制时会卡顿。可以尝试录制完成后分块错峰上传。或者检查下黑群晖硬盘写入瓶颈

103 天前

回复了 demonkhh 创建的主题 › 创业组队 › 前端一枚，寻找有意思的项目

@demonkhh 这里有一个非商业性质开源的 flutter 项目，技术栈上对前端非常友好，因为是全离线的客户端程序。
sudoku-flutter 是一个完整交互功能的数独应用，且可以完全离线生成各种难度的数独。最新版本新增了可以 AI 识别数独图片和解题功能。
部分 UI/UX 交互还可以进一步完善，如果你感兴趣的话可以跳转到 gihub 上查看项目内容以及下载体验最新版本的 apk 。
github 地址： https://github.com/einsitang/sudoku-flutter

217 天前

回复了 RedBeanIce 创建的主题 › Go 编程语言 › [支付宝 GO SDK] 寻求支付宝 go 的 sdk

综合 star 和 issue 数量来选择

219 天前

回复了 TristanYang 创建的主题 › 分享创造 › 越玩越聪明的数独小游戏

@GOliberation 这里有一个开源版，但是 flutter 实现，且仅支持移动端的版本： https://github.com/einsitang/sudoku-flutter

如果不需要应用还可以使用单纯算法的开源 lib ，有 nodejs / dart / go 语言的支持

289 天前

回复了 element90 创建的主题 › 奇思妙想 › 为什么没有一款专门运营躲猫猫的应用？

@x86
玩法上可以一直迭代啊，比如加入道具，“隐身”（让“鼠”在地图上短暂消息），“禁锢”（让某个玩家在一定时间内不能离开某区域）；加入徽章成就系统：“逃脱大王”，“终极猎手”，“守株待兔”等等，诸如此类可以继续迭代升级
而且这类 LBS 应用很适合社交，容易交友，且还是线下真实交友。
商业上也很容易，比如游戏内道具的获取可以通过一些商铺（ KFC/喜茶/霸王茶姬/星巴克等实体品牌门店）完成简单的任务（比如扫码打卡），也可以发展周边。
这些都是我在脑海里就可以构思出来的，而且我相信还可以发挥更多

290 天前

回复了 xiuming142857 创建的主题 › 奇思妙想 › 磁力 H5 在线播放能弄么？

比较困难，毕竟磁力链接提供的不是流媒体，现在的边下边播是将文件下载一部分到本地才可以正确解释，线上的流媒体格式和这种不一样，体积也不一样

360 天前

回复了 element90 创建的主题 › 程序员 › 为什么不结合签名的方式优化登录流程

@muzuiget @shellus 你们不需要考虑中间人问题，因为这个问题的建立是在“当时 http 盛行”的环境内。这个只是改良登录传输密码的环节，所以你应该对比的是“直接传输密码” vs “签名隐藏密码”的安全差异。

这个问题主要在于，为什么当时连这个改良都没有

360 天前

回复了 SculptureSand 创建的主题 › 云计算 › 你们是怎么防止云服务被刷的，例如对象存储

防盗链，但这个仅对 web 图片有效。

如果是文件分享的话，可以加一个请求授权流程，每次都向你的服务请求授权链接，然后你可以按需要给 oss 文件生成有时效的访问 URL ，这样你可以在你的服务端做相关的检查了

360 天前

回复了 element90 创建的主题 › 程序员 › 为什么不结合签名的方式优化登录流程

@i8086 那可能是我孤陋寡闻了

360 天前

回复了 element90 创建的主题 › 程序员 › 为什么不结合签名的方式优化登录流程

@tool2d 哈哈，可能是我孤陋寡闻了，因为当年我在参加工作的时候没有考虑到这么多，同时也没有任何人或者在任何团队上看到这种方式，所以完全没有看到这方面的应用，直到现在突然联想到这个问题发现当时没人这么做非常不合理。原来早就有了啊。。但是没有大规模形成实现标准，这也非常不合理啊

360 天前

回复了 element90 创建的主题 › 程序员 › 为什么不结合签名的方式优化登录流程

@flyqie 在那个年代，成本显然是低于 ssl

360 天前

回复了 blucas01 创建的主题 › 分享创造 › 支持远程调试的 “vConsole”

这种产品应该有很多啊，不过我不是做客户端开发的，所以不清楚具体的选型有哪些。

不过以前客户端的同事(Android/iOS) 都会接入这类似的平台，这些平台的 SDK 会帮忙收集客户端产生的日志，只是大部分情况下不会主动且实时上报到平台，而是本地记录，作为技术统计用的，当出现错误崩溃时也会记录错误日志栈，之后会将这些日志再上传到平台，所以他们可以在平台上通过错误栈和搭配其他统计信息进行远程 debug 。

所以主要区别是在于追踪非实时，并且只监测不控制。而我觉得这种方式更为合适，因为对于用户层面上来说，因为需要 debug 产品而对程序进行控制并不厚道，对于工程师来说，他们关注的点应该是出错信息而不是对于每一个客户端设备 debug ，所以只监测不控制，也不需要实时监测

2023-11-07 23:52:42 +08:00

回复了 infyni 创建的主题 › 分享创造 › [送码] InfyniDock ，全新 MacOS Dock 替代品，提高窗口切换的效率

2KSMNDH7IN8PT048 已用

2023-10-23 15:09:28 +08:00

回复了 element90 创建的主题 › 分享创造 › 开源 Flutter 数独应用，支持打包 IOS/Android 应用

@andyzhshg sudoku-go 有应用 DLX 的算法，只是在常规状态下速度不及 DFS ，只有在高难度的题目上才能有些许提升

2023-10-23 15:07:47 +08:00

回复了 element90 创建的主题 › 分享创造 › 开源 Flutter 数独应用，支持打包 IOS/Android 应用

@incu 是的，随机生成符合唯一解的数独，且整个项目目前是完全离线的

2023-10-22 00:06:40 +08:00

回复了 element90 创建的主题 › 分享创造 › 一个开源的 Flutter 数独应用,支持 iOS/Android

最近更新：
- 重构业务逻辑，并支持 Dart nullsafe ，开源可读性，jdk 更新至 11
- 多语言支持：中/英/法(机器翻译)
- 交互及功能音效支持
- 算法更新，生成速度更快难度调整更高，相应的 lib 提供 dart / nodejs / go 三种语言版本
- 数独功能为完备

应用完全单机，没联网没广告且完全开源 Apache License

2023-07-02 04:42:07 +08:00

回复了 oy9r 创建的主题 › 算法 › 如何快速的判断（证明）一个数独是否有且仅有唯一解？

我解决过你的问题，在对一个 puzzle 进行解题时(solve)一般情况下是不需要考虑数独是否唯一解(one-solution),因为一般情况下提交的 puzzle 如果存在非唯一解,则代表这个 puzzle 存在问题，而解题器的目的仅仅是为了解决计算问题，常规的算法有回溯/DLX：
- 回溯在处理难度不高的数独时速度是非常快且非常稳定
- DLX 在处理难度要求高的数独会相对于回溯算法有轻微的提升

但上述所表达的都是仅仅针对数独解题(solve), 但一个完整的数独也会考虑题目生成(generate),此时需要保证生成的 puzzle 具备唯一解特性,所以会在上述的回溯的算法基础上加上 "求二次解" 即单纯的 DFS

对于生成的速度来说,一个存在 55 个需填空的 one-solution puzzle ，在 nodejs 下平均 150ms ，而在 go 下普遍在 10ms 内

所以，单纯提供一个数独校验是否唯一解，仅仅就是几毫秒到几十毫秒之间

具体的算法库/应用你可以参考:
- sudoku-nodejs -> https://github.com/einsitang/sudoku-nodejs
- sudoku-go -> https://github.com/einsitang/sudoku-go
- sudoku-dart -> https://github.com/einsitang/sudoku-dart
- sudoku-flutter -> https://github.com/einsitang/sudoku-flutter

1 2

❮

❯