TronSoft没有手册。
没有 API 参考, 没有计划图, 没有论坛线程 解释为什么一个 commanda 拒绝关闭 。
如果你想理解它,你就打开数据库,开始拉线直到有道理.
这正是我所做的——几个月来,在我实际工作之外。
问题是没人记下 我是巴西米纳斯吉拉斯州米纳斯吉拉斯州 中等规模的Itaúna一家餐馆的运营经理 我也是唯一写软件的人 不是因为我受雇——因为这个餐厅运行着一个名为TronSoft的巴西ERP, 它建立在火鸟数据库上, Firebird 不像Postgres或MySQL那样的生态系统。
没有堆叠流过多的答案 。
除了薄的操作手册之外,没有官方文件。
供应商支持虽然存在,但速度很慢,没有规模到"我想在星期二晚上11点实现这个特定内部工作流程的自动化".
所以当我需要自动进行付款调节时, 在不触摸供应商脆弱的UI的情况下关闭commandas, 并可靠地触发财政文件排放(NFC-e)时, 我并没有什么可跟踪的。
我有一个现场制作数据库 和很多好奇心。
学习一个系统,通过观察它, 认为我开始了你所期望的: 打开桌子,猜想关系, 在测试环境中打破事物,直到我明白它们为什么破裂。
随着时间的推移,这变成了更系统的东西——我最后记录了大约40个功能单元的390个表格和514个外国钥匙,完全来自观察。
没有供应商文件,没有源代码访问.
只是结构,推论, 和很多试验和错误。
我学到的一些东西只暴露在压力下:火鸟的SQL方言有它自己的奇特之处——而不是一个.
小事,但它打破了你复制的每个查询 从 Postgres 教程。
初等钥匙不是自动递增 以你假设的方式。
它们是由发电机驱动的 (),如果你写出一个记录 而不同步发电机正确, 你得到沉默, 混乱的碰撞 以后。
复合主键意味着每个可见规则"正确"地插入一行,仍然可能以只有在真实的并发流量击中系统时才会出现的方式相冲突.
交易不会像你预期的那样, 直到你完全明白 自动承诺的能见度如何在这个特定的设置中起作用—— 我已经有了一些记录, 技术上,但是在需要这些记录的过程中, 还没有被看到。
最难的不是SQL 这是反向工程行为——当人类通过官方界面关闭一个连体时会发生的写作的精确顺序,这样我的自动化就可以精确地复制它,使财政排放服务承认它是合法的.
我最终实时观看了Firebird的内部监测表(()),在手动动作前后播放快照,本质上是给一个黑匣子来学习自己的规则.
为什么这比"把任务自动化"更重要 我的第一个自动化版本使用了屏幕自动化——字面上通过TronSoft的UI驱动鼠标和键盘来关闭相机,因为这是我唯一信任的界面.
成功了,但很脆弱 位于错误位置的一扇窗口,一个半秒后打开的对话框,整个被打破.
真正的转折点是当我停止把TronSoft当作一个UI来自动化,开始把它当作一个数据库来理解.
一旦我能够直接安全地写到, 和关于财政排放的表格—— 复制销售商自己的软件所期望的准确的 NULL 模式和实地惯例—— 自动化变得比黑客更接近于真正的整合。
从此开始生产,悄悄地关闭交易并触发财政文件,没有人碰老鼠.
我会告诉另一个自学的开发商 盯着一个没有文件的系统 我没有大学的计算机科学学位 我是自以为是的