The calculator at the bottom of the page is doing some weird calculations. If you have no incidents a year, it still costs you money. So do incidents that take zero minutes to resolve. I took apart the code, and this seems to be the equation in use:<p><pre><code> (revenueTarget / 8760) * resolutionTimeTarget * numIncidentsTarget * resolutionTimeTarget + numEmployeesTarget * avgEmployeeTargeRate
</code></pre>
This means revenue lost is correlated to the square of the lost time and the cost from employees is a static yearly cost.<p>There are a couple things wrong with it. The third * should be switched with a + and the last term need to be multiplied by the number of incidents.<p><pre><code> (revenueTarget / 8760) * resolutionTimeTarget * numIncidentsTarget + resolutionTimeTarget * numEmployeesTarget * avgEmployeeTargeRate * numIncidentsTarget
</code></pre>
Which if anyone at Call Stacking is here, just means changing<p><pre><code> o = (n / 8760) * e * t * e + i * r;
</code></pre>
to<p><pre><code> o = (n / 8760) * e * t + e * i * r * t;
</code></pre>
or more succinctly<p><pre><code> o = t * e * (n / 8760 + i * r)
</code></pre>
I'm assuming that's minified, so<p><pre><code> numIncidentsTarget * resolutionTimeTarget * (revenueTarget / 8760 + numEmployeesTarget * avgEmployeeRateTarget)
</code></pre>
Edit: With the correct math, the example is wildly different. It should be $37,277.81, not $87,991.23.
If someone is up for writing a Call Stacking client for the language platform of their choice, please email me.<p>This would be your reference implementation.<p><a href="https://github.com/callstacking/callstacking-rails">https://github.com/callstacking/callstacking-rails</a><p>I'm sure we could work out an arrangement.<p>jim@callstacking.com
Here's the client code for those that would like to inspect.<p><a href="https://github.com/callstacking/callstacking-rails">https://github.com/callstacking/callstacking-rails</a>
How does this work on the backend? Does it only trace method calls when an exception is thrown, or does it profile the call stack of every request?<p>Something I've been interested in is the performance impact of using <a href="https://docs.ruby-lang.org/en/3.2/Coverage.html" rel="nofollow noreferrer">https://docs.ruby-lang.org/en/3.2/Coverage.html</a> to find unused code by profiling production. Particularly using that to figure out any gems that are never called in production. Seems like it could be made fast.
This is very cool and useful.<p>Also it is only necessary because of the lack of type enforcement which means no code can be relied and on and all code has to be constantly inspected for new bugs. Ugh.
Recently did something similar for a java project using AOP. Basically adding an annotation to each method and logging the parameters before the method call and return values after the method call. Whenever there is an exception, a mail will be sent with the stacktrace along with the entire request path(including method calls, parameters and return values). Extremely useful for debugging and to proactively fix the issues.
After signup I see a typo in :<p><i>The trace URL will also be outut via the Rails log.</i><p>And the local usage section is hard to read white text on light blue background in this safari browser.
Would this mean that any data I happened to have in memory during the flow now permanently lives in callstacking's data stores? How does it handle all the data flowing through from a security perspective?
Some of this already exists to some degree: <a href="https://github.com/MiniProfiler/rack-mini-profiler">https://github.com/MiniProfiler/rack-mini-profiler</a>
The irony is that the issues this helps with <i>could</i> be solved far before production. Compile time, or some local runtime even. Just not in Ruby.<p>Nearly all the issues this shows you quickly are issues that static typing would prevent compile time, or type-hints would show you in dev-time.<p>I've been doing fulltime Rails for 12+ years now, PHP before that, C before that. But always I developed side-gigs in Java, C# and other typed languages and now, finally fulltime over to Rust. They solve this.<p>Before production. You want this solved before production. Really.