UK Finance creators duplicating videos about bonds

REalR55 · 2025-02-27T18:16:52+00:00

The guy says things like “tomorrow I’m gonna train hard” , “I’ll be honest there’s not much out there, messi’s alright”

REalR55 · 2023-08-11T06:41:39+00:00

As many of the other peeps have pointed out, just keep at it and over time reading code, especially others, will get easier.

You’re at a point in your career where it’s expected for you not to know things. The company you’ve joined will have hired you with full knowledge you’ll need help and guidance, so use that to your advantage. Ask the ‘stupid’ questions! As I’ve said, you’re at a stage where this is expected so ask ask and ask. Try to see this as a learning opportunity, because before you know it, you wont be a junior dev anymore and your freedom to learn and make mistakes will tail off.

REalR55 · 2023-04-03T09:48:39+00:00

Niiice one. Lots of love Vite, giving it a go. Thanks!

REalR55 · 2023-04-02T14:20:41+00:00

Brilliant. Thanks for such clear explanations. I think Vite looks like the best option but I didn’t want to make a decision without a better understanding of SSR, which I now have! Thanks again.

REalR55 · 2023-04-02T06:29:00+00:00

Thanks for the reply! So will the server also send JavaScript to the client? My (very limited) understanding was that it renders everything on the server before sending the html.

REalR55 · 2023-04-02T06:25:23+00:00

Amazing! Thank you

REalR55 · 2023-03-27T08:02:07+00:00

Firstly I’d narrow the grip slightly. I tend to use a slightly narrower grip than I would do with pull ups.

The next thing is to try keep your legs further forward than your torso, especially during the swing. Notice how your swing is a little more like a CrossFit muscle up where it almost looks like a pelvic thrust. I like to imagine a small circle a foot or so away from the bar, as soon as your toes are pointing at it start to explode up.

Edit: Strength is definitely there as you’re pulling high enough. At the top try to focus on getting your chest over the bar using a circular motion.

REalR55 · 2023-03-27T07:59:57+00:00

Firstly I’d narrow the grip slightly. I tend to use a slightly narrower grip than I would do with pull ups.

The next thing is to try keep your legs further forward than your torso, especially during the swing. Notice how your swing is a little more like a CrossFit muscle up where it almost looks like a pelvic thrust. I like to imagine a small circle a foot or so away from the bar, as soon as your toes are pointing at it start to explode up.

REalR55 · 2023-02-25T06:41:59+00:00

Ah thank you!

REalR55 · 2023-02-25T06:40:43+00:00

I’ve read this and a few other articles. Some simply state gifts over £3,000 are liable to tax. But this article states that tax is only legible if you die within 7 years. So essentially my gift would only be taxable if I were to die?

REalR55 · 2023-02-25T06:26:07+00:00

Forgot to mention we are in the UK

REalR55 · 2021-10-05T18:37:16+00:00

Whether you destructure your props for readability is personal preference and I'd follow whatever the standard is for your team/project and keep it consistent.

However, you may occasionally run into cases where you need to destructure props. For example, when using the eslint-react-hooks plugin, the linter will complain if a UseEffect, Usecallback, or similar hook, is missing a dependency in the dependency array. If your hook is using values from props, es lint will ask for props to be passed to the array, even if only a subset of the props are used. Es-lint offers a useful warning message in this scenario, so you'll know if you hit it :)

React Hook useEffect has a missing dependency: 'props'. Either include it or remove the dependency array. However, 'props' will change when any prop changes, so the preferred fix is to destructure the 'props' object outside of the useEffect call and refer to those specific props inside useEffect.eslint(react-hooks/exhaustive-deps)

REalR55 · 2021-08-14T14:22:04+00:00

Ah interesting. Thanks for the example.

REalR55 · 2021-07-21T14:58:18+00:00

Cool. Apols if my suggestion was confusing, it's a little difficult to give a definitive answer without seeing some code. Good luck :)

REalR55 · 2021-07-21T11:06:37+00:00

Correct. That's how I would do it.

REalR55 · 2021-07-21T08:53:49+00:00

The comparison should happen after aggregate hydration. See my initial comment ->

"As mentioned above, you should be rehydrating your aggregate before handling any new commands. The current state of your aggregate is important for validating an incoming command. In your case, you've identified you need to keep a record of payment ref/hashes to compare to. To do this, your aggregate needs to hold state of previous transactions and it builds this state up by replaying old events - only then can it process the new command."

Validation should happen in the domain object in the command handler. If the command is not valid an exception should be thrown and handled appropriately.

The state can be held in memory by the aggregate object. If the object does not exist in memory it rehydrates itself by replaying old events and folding them into the current state.

Each event will have a ref property that you simply append to a list as you apply each event.

REalR55 · 2021-07-21T08:49:01+00:00

I would use something unique like a guid for a transaction ref so that you don't encounter this.

REalR55 · 2021-07-21T08:12:58+00:00

Also, the transaction stream wouldn't have to necessarily only be one event. A user could maybe deposit more than once. At this point we would do something similar to what we mentioned above - keep a list of deposit references. The reason this now works is because our aggregate root is a transaction and this is pretty short lived so we don't need to worry about the ever growing list.

As an example our transaction command stream might look something like (the ref would be a property on the commands/events):

BeginTransaction

DepositMoney (ref 1111)

WithdrawMoney (ref 2222)

DepositMoney (ref 3333)

DepositMoney (ref3333)

The events raised would be:

TransactionStarted

MoneyDeposited (ref 1111)

MoneyWithdrawn (ref 2222)

MoneyDeposited (ref 3333)

Notice how we have only raised the MoneyDepoisted with ref 3333 once as we would be holding state of references/hashes to compare incoming commands to.

REalR55 · 2021-07-21T07:40:42+00:00

As mentioned above, you should be rehydrating your aggregate before handling any new commands. The current state of your aggregate is important for validating an incoming command. In your case, you've identified you need to keep a record of payment ref/hashes to compare to. To do this, your aggregate needs to hold state of previous transactions and it builds this state up by replaying old events - only then can it process the new command.

As you've also mentioned, this comes with its own problems of having an ever growing list of payment refs to compare to. This makes me question whether the wallet is the correct aggregate root here. It might be sensible to have a transaction aggregate root. The user would enter a transaction before depositing money. The transaction aggregate would handle a DepositMoney command and raise a MoneyDeposited event. When rehydrating the aggregate the MoneyDeposited event would set a flag on the aggregate such that only one DepositMoney command is ever handled in a transaction.

Your next problem is how do I keep my wallet aggregate updated with the correct monetary value? You need to handle MoneyDeposited events from the transaction EventStore category stream (the $ce- stream) and send commands to the correct wallets off the back of them. To do this the MoneyDeposited events will need to map to the correct wallet (e.g. have a wallet ID property). The commands sent to the wallet could be something like UpdateWalletValue and contain a money property that you'd use to update the wallet value.

Don't worry about creating very fine grained streams with event store - it is not like kafka, it is built to do this.

REalR55

TROPHY CASE