You can build your dimension tables in isolation of one another, each representing a different business object or domain. There can be the necessary transformations in here including business logic and rules.

The same dimension will be used across many fact tables, and the business logic will only need to have been written once. If it changes, you only need to update it in one place.

If the logic is used in multiple OBTs, you would need to write this logic (and maintain it) in each. Alternatively, you would have done it in an interim table. If this is the case, I would suggest to keep with a standard and have that interim table be your facts and dimensions.

How about this?

Do you mean a choc switch macropad? I’m pretty sure you should be able to get a kit, although not sure about something pre-built.

Depends on the definition of cheap, but you can find stuff on thingiverse and get it printed/print yourself if you have the hardware. Otherwise a tripod for each side seems to be fairly popular, either with gorilla grips or simply legs you sit on the desk.

I’d second this. Buy a switch tester, and have a play to see what you like. Some computer shops even have them in store to ‘try before you buy’. Next thing is the keyboard typo. Ortho? Split? 100% or 40%? FWIW I started out with an ErgoDox, and then played with layers and key layouts until I found something I was happy with. Then you can simply stay there, or if you’ve reduced your keys to something like 36-keys, there are a wide range of boards to choose from with slightly varying layouts and designs.

I only use one keyboard, but building them (designing the PCB and case, getting it printed, doing the soldering and updating the QMK code) is a bit of a hobby.

And I forgot Python. As a Data Engineer. Whoops!

• Tmux
• NeoVim
• Git
• FZF
• Fish
• ssh Lots of others, but these are the day-to-day

Once it’s up and running, I’ll be sure to post. It’ll be a Dvorak layout, as that’s what I’m comfortable with.

As an example though, take the left index finger. When resting over the home row on a standard keyboard it would be on the U key. The P key directly above and the K key directly below (QWERTY would be F with R above and V below). I’m planning to remove the home row. So the left index finger would have the two buttons - P & K. If I wanted to press U, I would simply press both buttons, so P & K together.

In all honesty, I have a concern that pressing both buttons will be double the spring weigh, and that might not be ideal on the home row where I spend most of my time. But, I’m currently using choc whites which have an operational force of 50g, and planning to use sunsets on this which are 40g. So while 80g across two switches is obviously more than 50g, it’s not double, and I’m hoping it’ll be workable. We’ll see!

Agreed in part. There are reasons there are distros, but I don’t think Op is suggesting to run LFS as a daily driver. More that they want to install it to show they can. And on that front, I’d disagree. Go for it! The book is fairly self explanatory. It does call out some choices early on with respect to package management. Stop and think at that point. Make a choice, then move forward.

That was my first thought too, however it seems to be used effectively by Ben Vallack on his 16 key board, and the concept is also used in stenography.

here you go.

There are issues with lemmy.world at the moment, so I’m using a second account on lemmy.ml.

If you scroll down a couple of posts, you’ll see the daily driver I’ve been using for a year or so. This is the next stage in the journey.

I’ve made it a single board, as I got annoyed with the two side moving independently. It might have been fixed by simply adding more weight, but that wouldn’t be as fun as a new build!

I’ve kept the key positions the same as before, however moved to columns of two keys instead of three. I’ve basically removed the home row. To get to the home row, you’d simply press both top and bottom together. So it should lead to less finger travel, but I’m interested to find out how well it works in practice.

As to the request for an explanation, it’s a 36 key, ortholinear, staggered and splayed split board.

36 keys - should be obvious Ortholinear - the keys are in line on the vertical axis, unlike a regular keyboard that has an offset between rows Staggered - the pinky column is set lower that the middle finger column, as my pinky is shorter and can’t stretch as far Splayed - if you naturally open an close a fist, your fingers don’t stay together when you open your fist, but rather they splay outwards. The keyboard follows that natural splay.

Other than that, it’s using QMK, and has 3 layers. I’ve not bothered mapping F keys, as I don’t use them. So layer 1 is regular alpha, layer 2 has numbers (or with shift has symbols), layer 3 has directional keys.

Also using home row mods for Command, Control, Option (work computer is a Mac).

Posting from lemmy.ml due to issues on lemmy.world.

Here is a link to the tilt things. I don’t have a printer, so got someone else to print them for me. They took a day to get used to, but I like them. Kinda like a poor mans dactyl.

Isn’t Apache Arrow a table format rather than a batch processing tool?

You could add SQLMesh as an alternative to dbt.