this, a thousand times.
Bank deposits are insured and yes it's a government thingy, but there is nothing that precludes *coin exchanges from setting up a private insurance policy.
I came in here to say just this! A fantastic book in so many ways. I read a lot of it on my own and learned more than in many of my classes on similar subjects. It taught me a huge amount about C, systems, architecture, memory and more. Very cool stuff. It starts with x86 but goes over at least the basic differences between it and x64.
Various things, a common aspiration was to try and fast track to a management position at a consultancy or blue chip where things were are more about spreadsheets than code. Others do technical work, but not strictly development like Q&A or technical support.
Some went into academia and some did other things altogether, I know at least one person who became a tree surgeon and another who is a session musician.
There are more jobs available, especially in places without software companies. Or people take those jobs temporarily while they look for other jobs, get promoted and end up following a different career track.
I'm fond of developer-QA folks that automate most of their pointing and clicking. There is, absolutely, a skill in finding bugs by exploratory testing, but someone who can combine that with automating previous tests (thus building up a regression suite) in a way that's maintainable is a real keeper.
You can, but:
- it's still advisable to wrap ints in some class to be able to distinguish ints that are already multipied and ints that aren't. It's also better cause then you can overload operators. I've written graphic demu using fixed point numbers (floats) without wrapping them, and it was very painful and error prone. So you still work on objects and not on primitive values.
- there's a problem with how much precision you need. Different countries specify their way to round up doing money calculation differently (even with the same currencies - see Euro). When you use ints you have the assumption about precision repeated all over your codebase, which make it harder to change when tax law changes or you want to support other countries. With BigDecimals most of the code is universal.
For many financial applications, you know precisely in advance how many decimal points you need to be able to accommodate. E.g. for UK VAT calculations, you are never required to work it out to more than four decimal points (and can then round to 3).
I sort-of agree with you, in that it is easy to get bitten, and that if people have a dynamic integer type available on their platform that's probably safest. If the choice is between using integers for fixed point vs. using double's though, I'd go for the fixed point any day.
The way it works is to use a giant bid or ask wall to push the price around. Say the asset has bids at 220 and asks at 222, and you want to push the price downwards. You put up an ask of an amount equivalent to maybe 6hours volume at 224 (an "ask wall"). Anyone selling will put their orders below that wall, and as you slowly move the wall downwards people will sell into the market in the expectation that they can buy again once you've pushed the price lower than where they sold.
This relies on the large wall not being an attractive offer for someone who has the purchasing power to obliterate it, which is where it occasionally fails. Generally, if the market starts to move against it with any force, it's pulled or moved further back behind other orders.
Another way this can be used is by putting up a wall on the opposite side of your real order to drive demand - i.e. in the scenario above, you might be trying to buy at 220. If you put up a huge wall at 224, people will be more willing to fill your order at 220 than if the orderbook was much thinner.
It seems this is called spoofing in the financial world.
That was a good explanation, except for the fact that I think you're referring to eg 220, 222, and 224 as the Satoshi/DOGE exchange rate, and by pushing the price downwards, you'll actually get more Satoshi for each DOGE.
Pushing the price "down" to 224 from 220 is very confusing and caused me to have to read your post several times to make sure I understood correctly.
I mean that putting a large sell order at 224 would make the buys (at the moment, at 220) move lower as the orders are filled by other people selling to them. You could then move the wall downwards, say to 221, when the sells in the orderbook had also moved downwards from 222. At this point the market's state would be something like buys at 218, sells at 220, and your wall at 221, effectively having pushed the market downwards from where you started.
Agreed on C.