Readit NewsThat would have been astronomically expensive given the enormous supply chain needed to produce charcoal to get that iron in those times.
I am sceptical on how they figured out iron stains are pothole fillings. I think much simpler explanation would be everyday items or metal pieces of carts getting stuck between stones.
I am tech lead and architect for large financial systems written in Java but have done a bunch of Common Lisp and Clojure projects in the past. I will still avoid any recursion and as people to remove recursion from their PRs unless it is absolutely best way to get readable and verifiable code.
As a developer your job is not to look for intellectual rewards when writing code and your job is not to find elegant solutions to problems (although frequently elegant solutions are the best ones). Your job is taking responsibility for the reliability, performance and future maintenance of whatever you create.
In my experience there is nothing worse than having bright engineers on a project who don't understand they are creating for other less bright engineers who will be working with it after the bright engineer gets bored with the project and moves on to another green field, rewarding task.
Most programmers learn about loops pretty much at the absolute start of their development experience, where they don't yet have a way to talk about recursion. Don't even start about tail recursion or tail recursion optimisation.
For example, one application of this was a long migration project where a large collection of files (some petabytes of data) was to be migrated from an on-prem NAS to cloud filesystem. The files on NAS were managed with additional asset management solution which stored metadata in a PostgreSQL (actual filenames, etc.)
The application I wrote was composed of a series of small tools. One tool would contact all of the sources of information and create a file with a series of commands (copy file from location A to location B, create a folder, set metadata on a file, etc.)
Other tools could take that large file and run operations on it. Split it into smaller pieces, prioritise specific folders, filter out modified files by date, calculate fingerprints from actual file data for deduplication, etc. These tools would just operate on this common file format without actually doing any operations on files.
And finally tool that could be instantiated somewhere and execute a plan.
I designed it all this way as it was much more resilient process. I could have many different processes running at the same times and I had a common format (a file with a collection of directives) as a way to communicate between all these different tools.
For the most part, I can see old books on bookshelves are still unedited. But maybe some other books have been completely destroyed due to not being acceptable to future readers/powers?
But I really hate it. I dislike when people do not understand that moral and social norms change over time and you can't blindly apply your current views to historical people who were brought up and lived in a different world.
I am pretty sure people in some distant future will think about us as heathens for eating meat, driving cars and wearing plastic. I hope they will be wise enough not to cancel us complete for this and hear out other wisdom we might want to pass.
Otherwise, you would have to contend with the fact that "real time" does not exist at all, as information about any event has to necessarily take time to travel to reach you.
So no "real time" coverage of anything -- the information always takes time to travel the distance.
What is not a correct understanding of how time works is claiming that it happened some thousands of years ago. No, from our reference frame it happened now. It is meaningless to say that it happened thousands of years ago because it happened thousands of years ago in some other, arbitrary reference frame.
Look at the changes that happened in the past and ask yourself:
* which people have been successful regardless of changes that happened?
I think almost independently of whatever you do in life, if you are absolutely best at what you do, you are probably going to be fine. Even if what you do is house cleaning, if you are best at houscleaning you are going to be fine. There is always going to be a millionaire or a billionaire who will prefer to have a human sweep the floor rather than a roomba. Or maybe a lab will prefer to have humans to do the work just to not invite potentially dangerous electronics on the site.
There is always demand for top level talent in any area. There will always be demand for human reporters, human drivers, human writers, human programmers, human graphics designers, human managers, regardless of the changes that will happen.
But it is possible that the demand will only be for top of the top of the top of people in each those areas and 99.9% or even more will be replaced and automated.
Another thing that can help is rare specialisation that is not worth automating.
One of the easier ways to find those rare specialisation is at a cross of two largely orthogonal areas of study. I like to think a lot of useful things happen through people who connect different, sometimes distant areas of knowledge / ability.
Another thing that helps people survive change is being a free agent. Don't be an employee -- be an enterpreneur with a mindset to learn and ability to pivot on a moment to moment basis. Learn a lot about life and universe, economics, trends, etc. Learn basis of how enterpreneurship works, how to find new areas that can provide value to people.
---
So if you are a developer, you have some choices:
* become best damn developer while you still can. Spend considerable time honestly learning your craft. Just completing projects is no longer enough to be safe, but outstanding developers who can complete projects will always be needed.
* learn deeply something else that can be connected with development. I know finances and it seems there will always be a need for people who know well development as well as finances.
* you could learn management/leadership skills. The trouble is, there is plenty of technical managers/leaders, just becoming one will not guarantee job safety. You will have to work hard to keep being strong technically while you are also trying to become very competent manager/leader.
* build on your development skills to become an enterpreneur. This is probably the hardest / riskiest path.
Other choices? Please, let me know... I am myself interested in this whole topic.
The process went something like this:
1. write code
2. get code review from my team (and/or the team whose code I was touching)
3. address feedback
4. on sign-off, merge and release code to production
5. monitor logs/alerts for increase in errors
In reality, even with thousands of developers, you don't have thousands of merges per day, it was more like 30-50 PRs being merged per day and on a multi-million line codebase, most PR's were never anywhere near each other.
It means any developer merges their work very, very rarely (20 days = 4 weeks on average...) and that in my experience means either low productivity (they just produce little) or huge PRs that have lots of conflicts and are PITA to review.
Because deploying the whole monolith takes a long time. There are ways to mitigate this, but in $currentjob we have a LARGE part of the monolith that is implemented as a library; so whenever we make changes to it, we have to deploy the entire thing.
If it were a service (which we are moving to), it would be able to be deployed independently, and much, much quicker.
There are other solutions to the problem, but "µs are bad, herr derr" is just trope at this point. Like anything, they're a tool, and can be used well or badly.
My hypothesis is that in most projects, the problems with monoliths are smaller, better understood and easier to address than the problems with microservices.
There are truly valid cases for microservices. The reality is, however, that most projects are not large enough to qualify to benefit from microservices. They are only large projects because they made a bunch of stupid performance and efficiency mistakes and now they need all this hardware to be able to provide services.
As to your statement that deploying monoliths takes time... that's not really that big of a problem. See, most projects can be engineered to build and deploy quickly. It takes truly large amount of code to make that real challenge.
And you still can use devops tools and best practices to manage monolithic applicaitons and deploy them quickly. The only thing that gets large is the compilation process itself and the size of the binary that is being transferred.
But in my experience it is not out of ordinary for a small microservice functionality that has just couple lines of code to produce image that take gigabytes in space and takes minutes to compile and deliver, so I think the argument is pretty moot.
(Also consider that the principal question the article tries to answer is not "are there more CAT incidents?" but simply "is there more CAT?")
I glanced at a few current (as of today) routes, e.g. CDG->SIN[0], which don't fly anywhere near the areas of heavy CAT noted by the heat maps. Hell, let's take a look at the flight mentioned, the LHR-SIN SQ321[1], where a passenger died in may (though, as the article notes, it was later determined not to be CAT): that one doesn't fly through any high-CAT areas (and in fact does fly through Russian airspace).
> giving them less options to avoid weather conditions
The entire characterization of CAT is that it is unavoidable because the cause often doesn't have all that much to do with weather conditions, and even when it does, you don't get (enough) advance warning.
[0] https://www.flightstats.com/v2/flight-tracker/SQ/335?year=20...
[1] https://www.flightstats.com/v2/flight-tracker/SQ/321?year=20...
The reason it is top-rated is because it sounds extremely reasonable. This is enough for most people.
I am not judging on whether the comment is correct or not, just answering why it is top-rated. I find nothing weird about it.