1作者: helterskelter大约 1 个月前
您好,我最近有一位家人去世了,她和两位丈夫育有三个孩子。这个人是指定的“家庭照片保管人”,考虑到家庭结构,分享照片不会像大家希望的那么容易。我想将她所有的家庭照片进行数字化存档(大量纸质照片,可能还有一些底片和数字照片(iPhone照片)),并将其提供给家里的每个人。我想知道是否有人做过类似的事情,并且分享一下哪些方法有效,哪些无效,或者您希望当初能以不同的方式进行等等。 我目前的计划是: 1. 购买一台高质量的扫描仪(有什么建议吗?) 2. 校准它(有什么技巧吗?) 3. 扫描照片,可能还有底片,扫描成TIFF或RAW格式(有什么特别的软件吗?我正在使用Linux,但如果需要的话,我可以买一台新机器) 4. 从他们的设备上获取我能找到的最高质量的照片副本,如果找不到原件,就从他们的社交媒体上下载照片等等。 5. 给文件添加元数据(日期、地点、照片中的人物、事件)。我们可能会把大家聚在一起做这件事,并尝试把它变成一个活动,一起回顾所有照片,尽可能多地回忆信息。 6. 对所有文件进行校验和 7. 保存到SSD,并刻录到M-DISC光盘上(同时附上存档过程的说明、如何验证文件、家谱、家庭时间线等) 8. 给每个人一个SSD和两张M-DISC光盘。 我还想创建一个在线访问方式。这里有什么低维护或零维护的解决方案吗?理想情况下,人们可以浏览家庭照片,获取低分辨率的副本用于通过Signal发送照片或上传到社交媒体,并且还可以下载高分辨率的版本。也许可以使用一个廉价提供商的静态网站?有什么建议吗? 我目前还处于规划的早期阶段,我只是想知道如何尽可能简单地实现最佳效果。这将是“未来”家庭照片的最终数字档案,我真的希望把它做好。
1作者: sellswordsoft大约 1 个月前
嗨,HN, 我开发了 JustBookmarks,这是一个小型的桌面书签管理器,适用于那些希望拥有一个独立于浏览器的书签“真相来源”的人。我之所以开发它,是因为我经常切换浏览器:Vivaldi、Zen、Helium、Brave 等。我希望有一种中心化的方式来管理书签,而这种方式独立于任何单个浏览器。我最终会得到不同状态的、相互之间同步程度不同的导出书签文件,管理起来非常令人沮丧。所以我研究了现有的工具,它们要么是在线的(Raindrop),要么是自托管的但过于复杂(Linkwarden),同时不知何故缺少最基本的书签管理功能——文件夹,反而专注于非标准化的分组方式,比如标签。 这些其他工具构建了自己的数据模型来引入非标准功能,需要你导出到受支持的文件才能将这些书签导入你的浏览器。所以,我决定直接使用最通用兼容的书签文件类型——Netscape 书签文件格式,这样会更简单。 基本思路是: * 直接使用 Netscape 书签 HTML 格式作为数据模型 * 你只需要管理一个 .html 文件 * 该文件可以直接导入到你正在使用的任何浏览器中 * 没有云端、SaaS、废话,它只是你电脑上的一个文件 功能: * 文件夹树 * 搜索(非常快) * 拖放重新排序文件夹和书签 * 记住上一次会话的状态 * 自动获取图标和标题 * 每次编辑时自动保存 * 能够将多个书签文件合并成一个 * 直观的键盘快捷键 ``` - ctrl+z 撤销,ctrl+shift+z & ctrl+y 重做 - ? 或 F1 打开帮助/快捷键菜单 - Ctrl/Shift 配合鼠标或箭头键进行多选,以进行批量操作 - F2 重命名 - 更多 ``` 它并不想搞花哨。没有标签,也没有同步平台或浏览器扩展。只有一个书签文件,你可以根据自己的需要进行备份或同步。 希望得到一些反馈,因为我发现我找不到类似的东西,这有点疯狂。我确信它已经存在,只是我找不到,这就是我在这里发帖的原因,希望将来有人搜索时能找到它。 为什么选择 Go 和 Svelte? 主要是因为我不想花太长时间开发它,我希望它存在,这样我就可以使用它。Web 堆栈确实非常适合制作 UI,但 Electron 在很多方面都很糟糕,所以我想选择一个替代方案。虽然 Tauri 可能是“更好”的选择,但 Rust 的工具堆栈有点重,编译速度也比较慢,而 Go 则不同。如果我设想几年后的情况,有人试图拉取和构建代码,我认为 Go 会更容易。Wails 采用了与 Tauri 类似的方法,只是用 Go 代替了 Rust,并且性能相当不错。至于 Svelte?我只是喜欢它。它很好。开发速度快,性能也快。也就是说。我强烈考虑将前端重写为 Fyne,这样就可以全部使用 Go,从而简化维护和构建堆栈。Web 堆栈/npm 世界中的任何东西都有很多变化。
10作者: garygao大约 1 个月前
嘿,Hacker News!我们是 Gary 和 Ian,正在构建 Chert (<a href="https:&#x2F;&#x2F;www.trychert.com&#x2F;">https:&#x2F;&#x2F;www.trychert.com&#x2F;</a>),这是一个 API,供企业大规模发送、接收和自动化 iMessage 对话。请查看我们的演示:<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=SRdwvVxMMoI" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=SRdwvVxMMoI</a>。 我们最初开始构建基于 iMessage 的产品,因为蓝色气泡界面、打字指示器和表情符号让代理对话感觉比 SMS/RCS 上的对话更人性化。这些产品包括一个在一周内覆盖 2,000 用户的 iMessage 代理构建器,以及一个每天发送数千条外发消息的自动化 iMessage 外发序列器。 难点在于 iMessage 并没有像 SMS/RCS 那样的原生 API。发送和接收 iMessage 需要一个单独的基础设施,而设置和维护这个基础设施非常困难,尤其是在大规模的情况下。 在与更多公司交流后,我们意识到 iMessage 的最高使用场景并非 B2C 代理或销售。它们包括客户服务、未接来电回短信、购物车放弃,以及在家庭服务、DTC 品牌和物业管理等垂直领域中捕获潜在客户,这些领域产生了最高的流量。 此外,这些公司通常需要额外的支持,例如自定义基础设施设置(例如,联系人卡片、区号或本地工作人员会话)、与其现有的 SMS/RCS 或语音代理系统的集成支持,以及一种可靠的方式来随着时间的推移扩大其业务量。 我们构建 Chert 是为了成为企业处理大规模 iMessage 对话的基础设施层。企业可以使用我们的 API 以编程方式发送和接收 iMessage,将回复路由给人工或代理,并将对话集成到他们已经使用的系统中。 为了在出站和入站用例中保持稳定性,我们构建了电话线路健康检查和 SMS/RCS 备用系统。我们还与现有的 SMS/RCS 系统、语音代理、CRM(如 Salesforce、HubSpot 和 Attio)以及 Slack 等工具集成。最后,我们允许企业通过自动线路配置和基于使用量的定价结构,从几条测试线路可靠地扩展到数百条线路。 我们正在与在 DTC、体育项目、物业管理和家庭服务领域进行对话式消息传递的公司合作,规模达到数百条线路。 我们很乐意听取您对这个以及 iMessage 可能有用的其他类似垂直领域的想法。欢迎所有评论!