2023-08-08T19:41:37+00:00

One, I think numbered params</a> have a lot of scope in removing some of the block cruft and overnaming of things across then</code> blocks. Especially if the next in chain is visually obvious.</p> +

@</span>client</span>.workflows(repo)
+</span>       .then { fetch_workflows(</span>*</span>1</span>) }
+</span>       .then { pick_active(</span>*</span>1</span>) }
+</span>       .then { transform_keys(</span>*</span>1</span>) }
+</span></code></pre>
+The above feels more natural and less noisy than naming each intermediate step with similar sounding variable names.</p>
+
The second one is a controversial (perhaps even wrong) point. It seems to me that since then</code> is just a function, the general debuggability of something going wrong in the pipeline is easier to find out in the chain.</p>
+
My (now fading) experience with threading macro debuggability has been less efficient; I end up adding taps and spies to figure out what part of the chain broke.</p>
+
I prefer an experience like:</p>
+

+write a pipeline</li>
+
pipeline breaks in expression number 2</li>
+
errors output nudges you clearly in the direction of just tweaking expression number 2</li>
+
make the fix and the pipeline starts working again</li>
+</ol>
+



2023-01-18T13:41:44+00:00
All these years of using Rails, I had no idea has_one</code> did this.</p>
+
</p>
+
More importantly with a relationship like follows,</p>
+
class </span>Model </span>< </span>ActiveRecord
+</span>  has_one </span>:build
+</span>end
+</span>
+</span>class </span>Build </span>< </span>ActiveRecord
+</span>  has_one_attached_file </span>:file
+</span>end
+</span></code></pre>
+If I create_build</code> on Model</code> if one already exists, it will:</p>
+

+Delete that Build</code>, create a new one and attach it to Model</code></li>
+
Kickoff an ActiveStorage::PurgeJob</code> and delete the file from GCS/AWS</li>
+</ol>
+This is highly uncomfortable.</p>
+


2023-01-10T14:58:17+00:00
I have been using return</code> a fair bit in transactions in Rails. In 7, these rollback the transaction and I use them as so.</p>
+
They obviously require very careful writing and to remember</strong> that the return actually just doesn't jump out of the block, it cancels the transaction.</p>
+
I prefer the fact that return</code> from 8 will throw an exception, but I've found that using Github::Result</code> around transactions as a pattern comes pretty close or is better (in some cases) already.</p>
+
Consider this example code that creates and merges a pull request,</p>
+
def </span>create_and_merge!
+</span>  </span>return </span>Result</span>.</span>new</span>(</span>ok?: </span>false</span>) </span>unless</span> create.ok?
+</span>  upserted_pull_request </span>=
+</span>    </span>@</span>new_pull_request</span>.update_or_insert!(create.value)
+</span>
+</span>  transaction </span>do
+</span>    upserted_pull_request.close! </span># close the PR
+</span>
+</span>    </span>if</span> merge.ok?
+</span>      </span>Result</span>.</span>new</span>(</span>ok?: </span>true</span>)
+</span>    </span>else
+</span>      </span>return </span>Result</span>.</span>new</span>(</span>ok?: </span>false</span>, </span>error: </span>"</span>Failed!</span>"</span>)
+</span>    </span>end
+</span>  </span>end
+</span>end
+</span>
+</span>def </span>create
+</span>  </span># creates a PR and returns a Result
+</span>end
+</span>
+</span>def </span>merge
+</span>  </span># merges a PR and returns a Result
+</span>end
+</span>
+</span>Result </span>= </span>Struct</span>.</span>new</span>(</span>:ok?</span>, </span>:error</span>, </span>:value</span>, </span>keyword_init: </span>true</span>)
+</span></code></pre>
+One problem here is that we're using custom Result</code> objects which are not very chainable. But the other more shape-y problem is that we're having to check the output from merge</code>, return an ok-Result</code> or else cancel</strong> the transaction and then</strong> return a not-ok-Result</code>. This not only feels like excessive work but also the use of return</code> is unfortunate to essentially carry out a rollback + value type scenario.</p>
+
With Github::Result</code> we can rewrite it much more cleanly,</p>
+
def </span>create_and_merge!
+</span>   </span>return </span>GitHub</span>::</span>Result</span>.</span>new </span>{ </span>raise </span>CreateError </span>} </span>unless</span> create.ok?
+</span>   upserted_pull_request </span>=
+</span>     </span>@</span>new_pull_request</span>.update_or_insert!(create.value!)
+</span>
+</span>   </span>GitHub</span>::</span>Result</span>.</span>new </span>do
+</span>     transaction </span>do
+</span>       upserted_pull_request.close! </span># close the PR
+</span>       merge.value!
+</span>     </span>end
+</span>  </span>end
+</span>end
+</span></code></pre>
+As long as merge</code> throws an exception, value!</code> will raise it, rollback (throwing an exception will rollback) and opaquely pass it further up to the wrappper Result</code>. This allows us to avoid return</code> magic and ugly raises in the middle of the transaction block and chain the exceptions up.</p>
+


2023-01-06T14:36:17+00:00
</p>
+
This is terrible.</p>
+


2023-01-06T14:25:59+00:00
I decided to add stricter linting to the codebase. Since I like what standard offers, I simply extended it with rails specific lints, in the following way:</p>
+
require</span>:
+</span>  - </span>standard
+</span>  - </span>rubocop-rails
+</span>  - </span>rubocop-rspec
+</span>  - </span>rubocop-performance
+</span>
+</span>inherit_gem</span>:
+</span>  </span>standard</span>: </span>config/ruby-3.0.yml
+</span>
+</span>AllCops</span>:
+</span>  </span>TargetRubyVersion</span>: </span>3.1
+</span>  </span>NewCops</span>: </span>enable
+</span>  </span>Exclude</span>:
+</span>    - </span>bin/**/*
+</span>    - </span>public/**/*
+</span>    - </span>vendor/**/*
+</span>    - </span>db/schema.rb
+</span>
+</span>Rails</span>:
+</span>  </span>Enabled</span>: </span>true
+</span>
+</span>RSpec</span>:
+</span>  </span>Enabled</span>: </span>true
+</span>
+</span>RSpec/ExampleLength</span>:
+</span>  </span>Enabled</span>: </span>false
+</span>
+</span>RSpec/MultipleExpectations</span>:
+</span>  </span>Max</span>: </span>4
+</span>
+</span>Performance</span>:
+</span>  </span>Enabled</span>: </span>true
+</span></code></pre>
+This ensures standard is used for ruby things, and rails, rspec and some other performance related checks in addition to it via rubocop.</p>
+
I came across this suggestion while fixing the 100 odd offenses it threw up,</p>
+
RSpec/NamedSubject:
+</span>  Name your test subject if you need to reference it explicitly.
+</span></code></pre>
+The fix,</p>
+
subject(</span>:run</span>) { create(</span>:releases_train_run</span>) }
+</span></code></pre>
+But what even is this? Isn't this just a let</code> really? You can't really use the is_expected.to</code> shortcut either since it's now named. I cannot possibly make the claim that this reads better.</p>
+
I think it's just one of those annoying rspec maximalisms.</p>
+


2022-10-11T15:44:45+00:00
Here's a spectrum of componentizing views I've been thinking about lately (in Rails):</p>
+
+Extract logical helpers and partials</li>
+</ol>
+They are often like stuffing away code inside a Module</code> and calling it a refactor. But it is cheap and effective enough to start off with. You often run into "too many allocations" issues, with nested views and partials. They also don't abstract state very well. Arguments for their limitations have been made ad naseam - ex</a>.</p>
+
Completed 200 OK in 86ms (Views: 83.6ms | ActiveRecord: 1.3ms | Allocations: 29347)
+</span></code></pre>
+
+Presenter objects / ViewComponents</li>
+</ol>
+Solid ideas here. Fair bit of upfront work required and you have to be meticulous about the granularity of your components. These claim to be very fast by precompiling templates at rails boot.</p>
+
+SPAs, building JSX components (or whatever else is out there now)</li>
+</ol>
+I'm not convinced I'd need to do this. I think Stimulus / Hotwired is powerful enough for all our needs for the forseeable future (famous last words). I still remember the joy of ripping out all the react from a previous codebase</a> I worked on and rewrote them in a much simpler, basic markup and js.</p>
+
#1 ➡ #2 hopefuly in a few months time.</p>
+


2022-10-06T12:23:54+00:00
When I originally kicked things off, I added a lot of big transactions around various api-call-surrounding-database-ops. This was knowingly a cheap hack to avoid bad state changes and delaying the inevitable: careful and tedious handling of errors and control-flow.</p>
+
I'm now slowly refactoring things to unpack these big transactions and I realize many of them are actually unnecessary. I'm employing yet another cheap Result</code> object to signify boundary-states,</p>
+Result </span>= </span>Struct</span>.</span>new</span>(</span>:ok?</span>, </span>:error</span>, </span>:value</span>, </span>keyword_init: </span>true</span>)
+</span>
+</span>def </span>good_op
+</span>  </span>Result</span>.</span>new</span>(</span>ok?: </span>true</span>, </span>value: </span>1</span>)
+</span>end
+</span>
+</span>def </span>bad_op
+</span>  </span>Result</span>.</span>new</span>(</span>ok?: </span>false</span>, </span>error: </span>"</span>Did not work</span>"</span>)
+</span>end
+</span>
+</span>operation.ok?
+</span>operation.value
+</span>operation.error
+</span></code></pre>
+This is a little bit silly, because it requires you</em> to ensure that value</code> is only present alongside the ok?</code> and the others are falsey in the error</code> case. But it is very simple and quick to get a refactor busted out.</p>
+I have used Github::Result</a> in the past, but recently discovered dry-rb</a> -- many of these look very sensible and immediately useful. Hopefully the next step!</p>
+


2022-10-05T00:19:39+00:00
</p>
+


2022-09-28T11:15:40+00:00
There are a few tight, but rare-enough race-conditions lingering about and they are constantly bothering me. They just exist as FIXMEs</code> in the code atm.</p>
+
Most of the these seem to be solvable by pessimistic row-locks, but I'm already dreading the littering of necessary but unintuitive placements of various row-locks throughout the code-base.</p>
+
Would modelling this as a pure declarative orchestrator help keep this in check?</p>
+
Not sure.</p>
+


2022-09-28T11:15:39+00:00
The views currently are a hot mess, giant nested ERB templates.
+I'm not convinced of jumping into ViewComponents</a> yet, since the shape of this UI is so nebulous and will definitely change dramatically and I do not want to deal with more objects and more abstractions and more code at the moment.</p>
+
I'll deal with the complex markup like it's 1999.</p>
+


2022-09-28T09:02:54+00:00
It's not terribly hard to come up with a state-machine DSL like aasm</a>
+by hand, but the ActiveRecord</code> support is very handy.</p>
+
I'm using it with an enum</code> against a status</code> field with the following options:</p>
+
{
+</span>  </span>column: :status</span>,
+</span>  </span>requires_lock: </span>true</span>,
+</span>  </span>requires_new_transaction: </span>false</span>,
+</span>  </span>enum: </span>true</span>,
+</span>  </span>create_scopes: </span>false
+</span>}
+</span></code></pre>
+The requires_new_transaction</code> is false</code> to avoid landing into unnecessary nested transactions. I'll keep my transactions explicit and intentional.
+The enum</code> allows me to play well with the Rails enum which already generates scopes, so I keep create_scopes</code> off.</p>
+
The requires_lock</code> is seemingly quite handy at first glance, since I require locking rows a fair bit because of the distributed nature of the app.
+But the level at which it locks is far too granular. I generally seem to require locking rows for far longer and more work than simply transitioning state and not everything can be sanely encapsulated in a before</code> or after</code>.
+I'd rather provide the library with methods that cause a state transition than the inverted way it currently operates: generating methods to transition for you and then locking within that event.</p>
+


2022-09-26T11:37:01+00:00
I'm finding keeping POROs seperated away from models/</code> a mental relief for some reason. I think I'm going to stick to it.</p>
+
</p>
+


2022-09-25T21:18:31+00:00
The log streams feature in Render</a> is a little bit strange. From the docs</a>,</p>
+
Render Log Streams forward logs from your web services,
+</span>private services, background workers, databases,
+</span>and cron jobs to any logging provider that supplies a TLS-enabled syslog drain.
+</span></code></pre>
+I hooked this up with datadog and it is indeed a syslog drain across all</em> services. This means my newly setup datadog is now filled with thousands of non-application related logs. Not only now do I have to filter all these out, but also pay for them.</p>
+
Surely a log streaming pipeline should have a minimum of a service-level (if not content-level) filtering as baseline features?</p>
+