If the random numbers can be 1-6, then yes, it would be trivial to attack. If the numbers are 300 bytes long, then it's impossible to predict.
> "I can try to be lucky and find your number by hashing random ones,"
If we were using sha-256, then you would be very impossibly lucky. There are 2^256 possible hash values for sha-256. It's extremely unlikely, that you would find a collision in the lifetime of the universe.
Here are some things I do to be reliably productive. To be clear, I don't do everything written below everyday (except limiting phonetime). They are tools to stop the downward spiral. Pick what works for you.
- Get StayFree app to limit your fun unproductive screentime. Getting bored is good for you.
- Generally limit things that gives you easy dopamine. It messes with your reward system.
- Clean up your home.
- Get a cheap A4 notebook. Write down stuff you need to do into bubbles all around the page to get them out of your head. Break down complex tasks into simple short defined actions. Connect the bubbles according to the order you want to complete them. Don't overcommit. It should be easy to follow.
- Sport helps
- Sleep and eat well
- Monday is the day when I'm the most productive. It's crucial to get rested during the weekend.
- Drink enough water
- Frontend development is less stressful than backend
- Try Headspace app
I believe it's a good compromise on timezone (8-9 hours is manageable), political stability, safety and reasonable talent pool. You can still relocate people from cheaper countries yo richer ones. You can convince Romanian to move to Germany, but you can't convince German to move to Romania.
I was a Cobol developer for a year in 2016 in Prague. It's hard to make a proper market research because the Cobol market is small. My limited point of view is, that it's not worth the stress. There is nothing new to build with it and young developers are there just to replace the old ones and maintain what's left. Even that it's hard to find a Cobol developer, i couldn't find a Cobol position that would pay more than a React developer.
I don't see how government reading through personal messages is gonna protect children. From all the possible solutions, this is the most useless and the most unsecure.
I had some issues with typegraphql years ago. I tried to split resolvers between modules and it behaved weirdly during unit tests. We also already used graphql-compose at job, so I wrote my own typescript decorator based solution on top of graphql-compose (https://github.com/captain-refactor/graphql-compose-typescri...)
My module worked as expected, and I tried it on my personal projects. Then I realized, how my projects code became confusing and result api was really bad. I abandoned development of the module, because it had flawed design from the start. The code-first approach doesn't really work well and result graphql schema is ugly, which makes it a bad solution. Generating typescript from schema gives better results. When you think about it, it makes sense, because your graphql schema is your applications api blueprint and it should be designed in advance, not generated from the result product. Also when I wrote idiomatic typescript code, it generated bad graphql schema structure. It's hard to create consistent api when it's scattered over many files filled with implementation details.
I already solved this problem for me. I use graphql code generator (https://www.graphql-code-generator.com/) to generate graphql resolvers on BE and angular services on FE.
I use MongoDB and database models are written in typescript. I want to manage db models separately from the API. With this approach, I'm type-safe from end to end.
Edit: I forgot mobile. Apollo Android client generates schemas from schema and queries. I've never written iOS app, so I can't recommend anything yet.
Author is wrong about the underlying cause of that disaster.
From my point of view, the cause is different:
1. Lack of design a.k.a. designed by coders
> At 5 months the team has happy path coded the entire feature list, the screens are ugly and non-intuitive, ...
It's obvious, that the product wasn't designed. Feature list isn't design. Competitors app isn't design. When you have UX/UI/API designed, it doesn't happen that the result product is ugly because of the lack of time. Lack of time may cause, that there will be nicely looking, but slow/incomplete/unreliable product. You need blueprints before building. It can be designed upfront by one designer who is in contact with user and stakeholders. When not, it has to be designed during coding by software engineers which are drowning in technical details and cut off from users.
So just having some more time wouldn't make it a good product.
Also with some plan, they could have created estimation based on something. That would help them to get a realistic timeline.
In the end, the boss and PM should have known better.
33% down is a lot on stock market but it's nothing unusual for bitcoin. People bought it for wrong reasons and now they couldn't handle it and sold their positions.