Case study · Code review in public
We read a stranger's Niagara tool in public. He implemented both fixes.
A member of the Niagara community publishes three free programs for copying component trees and driving link creation from a CSV. We read the code rather than the feature list, posted two defects and the fix for each in his own public thread, and six days later he replied that he had implemented the changes as they were laid out. The thread is open, dated, and on his community's forum rather than on this site.
- Niagara 4.15 framework code
- Public thread
- Two defects
- Implemented by the author
- Public API only
- No station used
The systems involved
What had to talk to what
| The tool | Three programs for a Niagara station, plus two ports to the previous generation: copy a component tree, and create links in bulk from a CSV of source and target slots. Published free on a community forum. |
|---|---|
| The framework underneath it | Niagara's own copy strategy, which the tool calls rather than reimplements: a Mark over the source, Mark.copyTo, a single keepAllLinks boolean, and a handle map that rewrites every link inside the copied set. Using the framework's own parameter is why the copies behave like a Workbench paste. |
| Where the review happened | A public forum thread, under our own name. The post, the reply and the dates are the record, and none of it is on a surface we control. |
The difficulty
What made them hard to connect
Adding a link never fails loudly. Once add has parented the link, the framework activates it through a helper that catches Throwable and only logs. So an unresolvable source ORD, a misspelled slot, a slot type the framework refuses to link, or crossing the station's licensed link count all return normally - and a CSV-driven linker writes LINKED. One typo in a two-hundred-row CSV yields a clean results file and nothing working.
Flatten mode can leave two live links into one input. With a trailing star each child is copied in its own call, so a sibling link's source handle is not in that child's map. It takes the keep branch and arrives still fed by the original folder's child, under the original slot name; the internal-link pass then adds the correct link under a hashed name, and the already-exists guard cannot see the preserved one because the names differ. Niagara allows more than one active link into a slot, so both propagate, the order is undefined, and the reverse operation removes only the hashed one.
It is somebody else's code, in public. A review in a thread that the whole community reads has to be specific enough to act on, limited to public API so it does not require a redesign, and honest about what was not done. The post says plainly that all of it was read off the framework code rather than run on a station, and that it should be treated as a code reading.
The work
What we built
A failure test that uses only public API
Read the link back after add, and treat missing, not active, or fault-flagged as a failure row. The same read makes the tool's verify honest, because a slot-exists test reports a link as present even when it never resolved.
A choice rather than a rewrite
For the duplicate links, two routes with their trade-offs stated: drop inbound links whose source still resolves under the source folder before recreating them, or pass keepAllLinks false for the flatten-mode child copies and accept that the target property resets to its type default.
The limits, in the post itself
No station was used. The reading is of the 4.15 framework code and the tool's own source, and the post says so in its last line - which is also why the author could check every claim against his own code before changing anything.
Now
What it does today
The author replied in the thread: “I have implemented the changes as you laid them out. Your explanation was excellent and thanks for helping make these tools better!” - and the thread is public, dated and not ours to edit. We have no client logo to show, so the reference we do have is a developer in this trade who read a code review, verified it against his own source, and changed his tool.
| Defects raised | 2 |
|---|---|
| Defects implemented by the author | 2 |
| Our post to his reply | 6 days, 27 September to 3 October 2026 |
| Code read | three current programs and two ports to the previous generation |
| Framework read | Niagara 4.15 copy strategy, link activation, handle map |
| Stations involved | none |
| Invoiced | nothing, and nothing was offered |
The stack
What it is made of
| What was read | the tool's source, plus the framework's copy strategy and link activation |
|---|---|
| How | bytecode and source reading, no station and no runtime test |
| Where it was posted | a public community forum thread |
| What changed | the author's own code, by the author |
Who did what
The reading is ours; the tool is not ours, and neither is the fix as it now stands. The author wrote all three programs, decided what to change and implemented it in his own code. We posted two defects and the reasoning behind each, unpaid and unasked, in a thread on his community's forum - so the record of it is not a page we can edit. He is not a client and this page does not imply one.
Check it
The evidence, not a description of it
Every link here opens the thing itself — a repository, a running demo, a note with the method in it.
Next step
Tell us the version, the hardware, and what it has to do.
You will get a written scope and a fixed price against it. If the honest answer is that you do not need us, you will get that instead.