SinHub's Blog

之前做数据处理的时候为了方便用 Python 做过一些基于 Windows 的 GUI 应用，当时仅仅是一个从无到有的过程，而且为了便于打包分发，干脆就用了自带的 Tkinter ，所以界面就有点原始了。然后就一直这么用着过了这么些年，发现给增加新菜单、新页面的时候感觉特别别扭，从页面布局到事件响应。鉴于之前也用过 wxPython ， kivy ， PyQt 之类的框架，使用的时候基本上不是常用的组件都要查阅文档，而且事件响应各有各的用法（比如 wxPython 需要 Bind 绑定， Qt 习惯使用 slot/emit/signals 等），太久没用复习成本有点高昂了。至于别的选择，比如流行的 electron 等，不好把 Python 的数据处理模块重新用 JS 实现一遍（数据处理还是 Python 香啊）。突然就想有没有一种 Python 的前后端分离的桌面开发方式，让我可以用编写 Web 网页前端，后端使用 Python 做处理，然后还能封装成桌面应用 —— 然后就发现了 pywebview 。

转眼就到了四月份，当初信誓旦旦勤更 blog 的诺言已经烟消云散(一时摸鱼一时爽，一直摸鱼一直爽)，想到这里不禁感到痛心疾首 (;´Д`) 。最近刚忙完个前端项目，转头就回头投入到另一个智能化社区的项目里头；然后又碰到了那个业务上老生常谈的问题，无论是小区楼宇的划分，还是组织的上下级关系，抑或是最常见的论坛评论引用都会出现：怎样存储一颗树？

“—— 不会吧，都 2021 年了，为什么不把树存到 JSON 里去，大把的 NoSQL 支持 JSON 结构，哪怕是关系型数据库也有一堆可选的。”诚然，使用 JSON 最大的好处就是 维护整棵树 都比较方便，但是当我们要更新树的节点、查询节点的关联关系，都不如纯关系数据库那么方便。不过既然是老生常谈的话题，集思广益一下，终会有适合自己的方法。这次就列举了四个常见的范式，所以篇幅可能略长（不过和翻译类 blog 对比可能还不算 (´_っ`) ）。

最近在看 CTF 相关的内容，也过去看雪那边练了下手，毕竟现在 KCTF 秋季赛正火热进行中 🧐 。前菜 Web 题一般都是小试牛刀了，涉及到了 SSRF 和 XXE 。之前对于 XXE 也不是十分了解，结合实际题目还有网上资料做了一下加强学习，然后在这里简单的聊一下。

最近在看 Twitter 的 Snowflake 算法，打算用 Python 来自己实现一边这个 IdWorker ，源码是用 Scala 写的，但是也不难看懂大概逻辑，顺便回顾下 Python3 里头 bytes 的操作以及单例模式。

之前负责的大数据项目里，由于客户提供的云环境过于特殊，Spark 的版本太老，用不上 Apache Livy ，迫于无奈只能自己实现一个较为直接（菜鸟）的 Spark Restful 交互，当时有一个难点就是需要将 PySpark 运行的某些信息额外存一份到 HDFS 上。当然 RDD 存 HDFS 上对于 Spark 来说是非常方便，但是却怎么也找不到 PySpark 直接操作 HDFS 的方法，当时是参考了 Raven’s Blog 的一篇文章解决了，也了解到了 PySpark 用于操作 Java 对象的库 Py4J ，然后心血来潮，稍微归纳一下目前自己用到或者摸过的 Python 和其他语言的互操作库，纯粹分享（水一篇 blog）。

最近在使用 golang 进行项目开发，而公司的主要数据库还是 Oracle ，在尝试 golang 连接 Oracle 上着实碰到了钉子，没想到都 9102 年快结束了 oracle 依然没有提供 golang 的驱动，目前现有的库只能基于 oci8 来调用，而大部分对 Windows 上进行开发都不怎么友好（毕竟要交叉编译），我选择的是 go-oci8 ，开发机器是 Windows10 64 位，当中的过程在这里小小的分享一下。

Sentry 是一个开源的实时错误追踪系统，可以帮助开发者实时监控并修复异常问题。它主要专注于持续集成、提高效率并且提升用户体验。Sentry 分为服务端和客户端 SDK，前者可以直接使用它家提供的在线服务，也可以本地自行搭建；后者提供了对多种主流语言和框架的支持，包括 React、Angular、Node、Django、RoR、PHP、Laravel、Android、.NET、JAVA 等。同时它可提供了和其他流行服务集成的方案，例如 GitHub、GitLab、bitbuck、heroku、slack、Trello 等。目前公司的项目也都在逐步应用上 Sentry 进行错误日志管理。

上一篇 blog 主要介绍了 Python import 的机制，其中的 finder 、 loader 、 importer 以及 import 协议都和 PEP320 密切相关。PEP320 的内容倒不是很长，也主要是一些前因后果的内容，同时作为（曾经）新提出的标准，现在也以通过标准库的 importlib 得以实现了。不过，作为前文的扩展内容，也是值得一看的。这篇依然是译文，感觉个人的翻译能力还是有限，不过多少还是会坚持下去，如果有不正确的地方，也欢迎指出 🙂。

对于 Python 的 import 机制，一直以来感觉都一知半懂，尤其是对于 Python 这种非常 freestyle 的操作，在项目组织上没有什么固定的目录结构可言，如果部署或者打包的时候发生 import 出错或者失败，有时候确实会丈二和尚摸不着头脑，充其量就改改 sys.path 就完事了。但是这样的实现无疑是 ugly 的，要想明白 import 的工作原理，还是得好好地啃啃硬骨头。

所以这篇 blog 就这么来了，内容会包括：

• 模块和包的基本介绍
• 默认的 import 流程和常见的 hack 手段
• import 协议以及相关对象：finder、loader、importer 和 spec
• 两种 import hook

之前貌似说要再重新学习一下 DB API 的内容，但是拖延症发作，好不容易才看了一遍这份 PEP249 的内容，顺手又作了一下翻译（应该是继 PEP3333 以来的第二篇）。不过本人能力有限，可能还是会有一些蹩脚的地方，请谨慎食用😜。