Sushruth

backend engg · spring boot + grpc in prod · built an app running a real lab's daily ops · 学汉语

[Sushruth @TreeApostle]

Annoy the world into letting you succeed

[Sushruth @TreeApostle]

@jackedAJ how abt htmx :D

[Sushruth @TreeApostle]

@vennictus bro even said it was a 10/10 bleed out spot 😭

[Sushruth @TreeApostle]

@avrldotdev wow, saved both 🤙

[Sushruth @TreeApostle]

@Hi_Mrinal 100%

Thats the exact thing I did in my intern, majority of my time was spent checking the logs of all the workflows. In hindsight, it was the best way to learn how all microservices connected end to end.

[Sushruth @TreeApostle]

issok man, sometimes if our body is not used to resting it may feel like this is not the right thing to be doing

Feel it all, then decide what you want to do it.

Being aware of it is already good. Just do not focus on what has passed and focus on what can be done

you will be fine 🫂

[Sushruth @TreeApostle]

@learn_with_san console.log is our debug tool ofc we have used it everywhere XD

[Sushruth @TreeApostle]

@SahilExec The callback is in the form of a block so it should have a return statement but doesnt so the result is not captured anywhere, it just gets computed then thrown away

remove the braces for a clean 1 line function or change the aggregation line to 'return sum + order.amount;'

[Sushruth @TreeApostle]

@sadkatwt man. i started watching cosmos yesterday and i wonder if we will ever get to explore the vast universe before our own greed and nature takes us down

[Sushruth @TreeApostle]

soft: moves head commit ptr but leaves our changes staged, ready to recommit
mixed (default): moves the ptr, unstages the changes but they stay in the working dir
hard: moves ptr and also deletes everything, staged and unstaged gone

basically try to avoid hard for large code changes

[Sushruth @TreeApostle]

@EOEboh Good post!

[Sushruth @TreeApostle]

@SahilExec no because that just hands user the ability to roleplay

role changes should come from a separate admin-only path, not the update body

[Sushruth @TreeApostle]

@deepp2108 wow what a W. keep going 💪

[Sushruth @TreeApostle]

@SumitM_X no because base64 is just an encoding not encryption its just a way to transform data for comms or transportation purposes or for saving in db, its not encryption so its not safe just because its base64 encoded

[Sushruth @TreeApostle]

@kayleecodez Bugs getting fixed might be but what if your fix goes to the wrong files XD

[Sushruth @TreeApostle]

@SahilExec Any feature on the frontend is just a suggestion. Real fixes should always come from the backend or database side.

Here the fix would be to ensure duplicate users arent created ie a unique constraint on email.

[Sushruth @TreeApostle]

slightly offtopic, I think fewer features is in itself a feature.

if the initial user base hates the increasing list of features which makes the app cluttered, you might lose their trust. That is unless you have explicit proof that the users joined with the hope of new features.

Having said that, for an early stage product, clearer distribution beats the odds.

[Sushruth @TreeApostle]

@Shra_va_ni job rejections

[Sushruth @TreeApostle]

@devXritesh 💯

[Sushruth @TreeApostle]

Today i watched a short interesting video doing a slight deep dive into postgres MVCC.

A few points from what i understood (might not be fully technically sound):

- Each row in a table has its own set of hidden metadata columns. all of these together form a tuple, stored at a physical memory location

- These metadata cols store various info. For eg: ctid stores the physical location of a tuple, xmin stores the txn that formed that tuple, xmax stores the txn that makes that tuple irrelevant.

- A nonzero xmax usually means that tuple isnt the latest version of that row anymore.

- so basically, for every write on a row, a whole new tuple gets formed

This then made me wonder, if every write forms a new tuple, and a row ends up with say some 1000 tuples, does postgres manually parse through all of them each time I select that row until it finds the latest?

Not so.

Firstly, the tuples dont stay around forever. postgres has VACUUM, which keeps an eye on dead/outdated tuples and marks their locations to be overwritten by new tuples. So the pile doesnt grow infinitely.

Secondly, we dont usually scan the whole table anyway. With an index, we have something that points straight at the candidate tuples, and it just checks each one for visibility (is this the version my txn should see?) instead of walking every version by hand.

so yeah, that felt like a short but genuinely interesting look at postgres infamous MVCC and i figured id share here :P

btw here's the video in case you wanted to learn more: https://t.co/hNpuvwKwKY

[Sushruth @TreeApostle]

@tanujDE3180 I definitely agree

[Sushruth @TreeApostle]

INNER JOIN - return only rows that match on both tables

LEFT JOIN - return all rows of left table and matched rows from right table

RIGHT JOIN - return all rows of right table and matched rows left table

FULL OUTER JOIN - return matched rows, with nulls when there's no match on the other table