Nothing here yet.
Nothing here yet.
No blogs yet.
Minimaps and code folding are not an excuse for lousy coding. They basically exist to help you navigate through bad code, which is unfortunately very frequent in a life of a programmer. Remember, you're not always reading your code, and neither will you always write good code.
"Build" can mean a lot of things, like: Compiling source code to byte code Transpilling high level code to a more low level language Raising and provisioning a machine to run your server etc. So, based in what they all seem to have in common, I would define build as: A setup process before something can run properly
V8 is indeed very fast. There's plenty of data on that (assuming I wasn't being lied to for years, from multiple different sources :D). The thing about Node is that is was build for handling every blocking action asynchronously by default. This doesn't make it faster, but it increases the concurrency (meaning more clients using the system at the same time). You can achieve the same async pattern with other languages like python, even faster maybe. But it's not like "enforced" in the language's culture, you know? Django, for instance, which is one of the big python frameworks, won't do this out-of-the-box. At the end of the day, it doesn't make thaaat much of a difference. Scaling applications horizontally is quite easy. In the real world, the REAL PROBLEM is your database. Trust me, if you want to build something that scales, worry less about your language and worry more about how you're accessing your data.
You should consider tests to be half of your work. If you deliver only the main code of a feature, you delivered 50% of your work. Once you start thinking like that (which is good for you as a professional), you'll start forcing yourself to always write tests. The more tests you write, the faster you'll become at writing them. Basically, you start reaping the full benefits of testing when it becomes a habit in your daily routine. That said, I know this is very hard and time consuming. My advice to you is to start breaking down your tasks into smaller tasks (if possible), and estimate your activities taking the tests into consideration (e.g. time*2). So, if you think you have a 2-day task at hand and cannot break it down to smaller tasks, make it a 4-day to account for testing. This may seem like drastic at first, to spend 50% of your time on tests, but on the long run, the tests pay for themselves in terms of saved time. Also, it's the only human way to ensure your code actually works. The alternative is manually testing everything, everyday (needless to say, this is not likely to happen). So, to summarize: my advice to you is always write tests (or at the very least, try really hard) even if it takes a long time. At first you'll feel like "wasting" a lot of time, but in time you'll come to appreciate the tests you wrote and realize they save more time than they cost to write. Of course you have to get good at it. Remember: test code should be cared for as carefully as production code. They are both EQUALLY important parts of the feature you are delivering.