Day 26 - Start plugging a knowledge gap

Do you recall thinking something like “I really should know more about X”?

Today’s your chance to do something about it.

Please spend 20 minutes researching that thing.

Maybe it’s a technology in your stack that you feel a little guilty for not knowing.

Or maybe it’s a new tool that seems exciting but you haven’t had a chance to look into.

Don’t worry about a full exploration. Just chip away a little at your lack of knowledge. One step at a time :slight_smile:


Nice way to end the week! I spend the morning reading more about how the TestScheduler in RxSwift can be used to in our unit tests to avoid waiting when testing code that use debounce our throttle.

1 Like

Ended up reading about Kotlin Coroutines, because apparently that’s how the cool kids do concurrency now :man_shrugging:

I dove into a relative new testing framework I wanted to look into for a while. This was a nice queue to actually start reading about it and trying it out :slight_smile:

I have so much in my wishlist. Recently we decided to rewrite our UI in tailwind, so I spent some time playing around with it.

I’m currently doing a 100daysofcode challenge to learn Supercollider, does that count?

Also, restarted my elisp track :v:

The project I joined last week uses Kubernetes which is new to me. Onboarding and setup was successful relatively smooth. While I can run most of it locally, I’m not super familiar with the tooling yet. So I used this time to read up on kubectl.

Actually, I am so found of learning new things that I had to limit the time I spend on it. For this reason I keep a “R&D” list with various topics I would like to learn.

Anyway, yesterday I spent whole day learning how to query PostgreSQL with JSONB fields (it was task for actual project), so today I spent some time trying to learn about EXPLAIN report. One takeway is, that on Postgres EXPLAIN Visualizer (pev) page I can paste query with JSON formatted EXPLAIN output to see the report nicely visualized.

thanks Harvey Justin

1 Like

The default Rails way to have the JS logic for all your pages included in one large application.js bundle always felt weird to me, even for a brand new project. Back in the old school asset pipeline pre-Webpack and pre-SPA days, I usually had an application.js for general dependencies, and a specific your_page.js to execute JS targeted at a specific page (JS sprinkles with jQuery).

So today I quickly brushed up on what such a setup might look like in the modern world i.e. with Webpack.

Specifically I read up on webpack’s SplitChunksPlugin and how to make it work with webpacker. This allows you to do <%= javascript_packs_with_chunks_tag 'your_page' %>, which includes both a common application.js-like bundle as well as a your_page.js file, very similarly to the old school way I used to do things. Very cool!

I think I’ll do that for my next full-stack Rails personal projects. Or not! But in any case it was interesting to learn about that.

This morning I spent some time looking into Kubernetes, something I’ve been wanting to learn for a while. There wasn’t much I could learn in 20 minutes, but I did find some good resources and tutorials that I will follow in the near future!

1 Like

We leverage laravel’s app service provider to inject settings early on so that our vue pages’ footer has the information it needs. If we do not, we fail to get custom terms and conditions links that the customer wants, and they have control over where those terms are and what they look like, hence a dynamic entry there.
With this done, SO many unit tests fail, especially functional tests because asserting 200 on pages with no settings fails, because the page cannot load without the terms information from the DB.
I could not work out why test fixture setUp would not create this from the settings factory.
And even after I was forced to work around this, the tests still fail because we refresh the test database each time.
All of this is because of how laravel’s data providers work and when framework things are available, and at setUp these are not available, so no factories.
And even with the workaround, the tests fail because by the time the test has injected settings, the app service provider has already loaded (failed to) and the settings were not there yet.

I learned this, and know a little more of the laravel framework now.

TL;DR developer does not know his framework well enough and failed many times before succeeding.

1 Like

“I really should know more about JS and RN" :nerd_face: