lmilcin

I very much disagree.

Yes -- it is important how you rectify those mistakes.

But being quick at rectifying mistakes does not yet make your actions professional.

> I agree with you, but open source software is given as-is, in any context,

But if you are calling somebody or something "professional" what you are saying is they act as if they were doing it in a certain way. If they don't follow the practices it does not matter if they are doing it for free.

It is like saying a kid is doing something professionally (even if he is not) and argumenting that it is because he isn't paid for it.

Professionalism, in my opinion, includes taking reasonable precautions to prevent the problem from happening.

If you are professional you know what kind of potential problems might happen and you know what are reasonable possible approaches to handle it.

If security of your piece of software relies on default values of some settings I would reasonably expect you to have automated tests to verify that these settings have correct values.

Next time you hire an electrician who causes damage to your house because he did not follow procedure to wire it correctly, will you be still calling him "professional" because he quickly removed the short?

I would add that seeing somebody "forgetting" NUMA makes it likely there is a lot of other problems.

NUMA isn't something you "forget" when you try to test bandwidth limits. It suggest lack of understanding of how that stuff works.

It is as if somebody failed to reach hard drive transfer speeds and they "forgot" they need to be looking at the access pattern.

First of all, there is also copper conductor in it.

But the most important is, I think, you are mistaking voltage and current.

Resistance will limit current, but it will do nothing to voltage (except for fast transients depending on capacitive properties of the line -- sorry, there must always be some exceptions to every rule).

1M volts put to a conductor will still be 1M volts regardless of wether the conductor is 1ohm or 1M ohm.

Remember, electronics is mostly fried by voltage, not by current. For high current to damage electronics at nominal voltage it must have an internal fault -- short circuit, for example, that causes it to draw more power than necessary.

High potential, on the other hand, causes electrons to go all sorts of ways they are not supposed to go, causing damage to all sorts of things that are not supposed to be penetrated by electrons.

You can damage sensitive electronics by waving your hand over it. You don't even have to touch it -- just the fact that you are moving some electrons on your hand causes electromagnetic field (moving charge == electromagnetic field) that causes potential to be induced in internal electronics (conductor in changing electromagnetic field == induction).

Just read about why exactly electronics is distributed in those funny metalized bags.

They can already identify a person from typing, gait or even how you move your mouse.

It is either very dishonest or extremely stupid for an expert to say mm waves can't be used to identify a person.

I am developer/architect/tech lead with over 20 years of experience in operations, system/embedded/backend development (C/Java), managing technical projects and teams.

Looking to volunteer for a nonprofit.

But in case of sports betting the money don't come from other people, it comes from the house.

Also, if some people elect to be locked indoors they are also probably safe from the original deadly virus.

I mean the crafted virus would have to be significantly more transmissible than the deadly one it tries to outpace.

This has nothing to do with your statement on how fast we are able to deploy a vaccine vs infect population with a virus.

Obviously, vaccine is preferable IF people were getting vaccinated.

Also, it is normal for viruses to infect vaccinated people. The point of most vaccines is not to protect any single person, it is to protect the population. This happens by making it difficult for the virus to find a new host.

When enough people are not vaccinated the virus is perfectly "happy" to mostly spread through unvaccinated population and hit the vaccinated population in the process.

Think about this way: imagine a town densely built with wooden houses.

Any fire would quickly consume entire town.

Now imagine replacing 25% of wooden houses with brick houses.

The fire will still consume entire town and it will still consume most or all of the brick houses.

Does this mean that brick houses spread fire as readily as wooden ones?

That's why I mentioned populations sabotaging the system.

I know this might sound like a radical idea, but vaccinations can only be effective when people are actually getting vaccinated.

Well, a virus can be contagious without symptoms. COVID in particular starts spreading before symptoms suggesting you could have respiratory virus without people even being aware they are infected. And we know most people are not even aware they were sick or they had only mild symptoms.

The issue with COVID is that some people are hit hard and a lot of people develop hard to detect complications.

If you could modify the virus to avoid complications and avoid hitting some people very hard, you could have pretty effective way to innoculate population.

The thing you are after is a virus that has same basic spike protein for your immune system to recognize and only enough mechanism to multiply itself.

Stupid idea: create artificial virus that spreads faster than natural one but without negative health effects.

Nobody would admit that, but that could potentially be most efficient way to combat a future global pandemic (assuming people keep sabotaging the system by not cooperating).

Don't be so naive to even suggest that these businesses would allow you to earn money on them.

These only exist to earn money for their owner. That's it.

Just like any other establishment, you will be thrown out if you find a way to earn money on them rather than loose your own. Any casino that notices you are earning money regularly will do the same.

This game is a passing fad, not a sustainable business.

Most current users will get bored and move on to something else.

Most of the worth is probably in people that can put up a successful product.

The problem with Clojure is that it is too good. It gives you, the programmer, too much freedom.

Most people do not have problems that require so much freedom.

Most people do not know what to do with that freedom -- they don't have enough experience actually organising their applications.

Most people benefit from using a language/framework that requires them or at least rewards them to put things in a certain way. For example Java Spring rewards people for following a certain application design -- you can break rules but then you are on your own and Stack[Exchange|Overflow] examples can no longer be copied/pasted directly into your codebase.

As much as I love Clojure, every single corporate Clojure project I have seen in the past was an utterly unmaintainable mess.

I have never actually participated in a Clojure project (I use Clojure mostly for rapid prototyping/PoC-ing), but what I figured is that Clojure requires minimum maturity from the developer and especially drive to be constantly simplifying things -- which is unfortunately very high bar. Most developers I work with / interviewed do not really understand what it means to refactor and simplify. Most people are only focused on the part of the work when they get something to produce expected values and everything else just isn't high priority in a corporate environment.

Make sure your big $$$ are not available easily. Find a bank/brokerage that will actually do their job verifying you before they dispense your money.

You are not able to defend yourself from targeted attacks. Period.

It is one thing to try to defend from attacks of opportunity (ie. viruses, ransomware, etc.) and another from people who actually know their job and for some reason find yourself attractive target.

Thus, the best way to respond is to not make yourself attractive target in the first place and if you need to have attractive things somewhere -- separate them from everything else.

Not a surprise, really.

I have battled so many times with smug novice "engineers", fresh from their CS courses, pointing, without even thinking twice, O(n^2) or even O(n^3) algorithms as errors on code reviews. This without taking into account the size of the input or the underlying machine executing the code.

It is my constant source of amazement -- to interview yet another candidate who can write any number of sorting algorithms from memory on a whiteboard but who can't tell whether a linked list or an array list insertion is going to be faster for a given application.

Undersea cables use steel for strength and additional conductor to power repeaters.

Fiberoptic needs repeaters every couple hundred kilometers, so everything crossing any ocean is actively powered.

The damage to the cable would come from difference in potential at the ends of the cable. The cable might be at the ocean bottom but it could still get fried if you apply high voltage that could kill repeaters. And without those the cable is useless.

Basically, greatly simplifying, in a solar storm any long conductor might be subjected to high potential difference (potential difference == voltage). It does not matter if the middle is exposed but enough of it needs to be exposed at the ends. So a lot will depend on details of how the cable is actually terminated. And it should be possible to engineer it (ie terminations) so that it is safe from a storm.

HN is for interesting content. If you can make something interesting, then it is welcome.

> I find it interesting that all these technologies that are supposed to make our lives easier really just end up transferring power from one group of people to another.

But that's what affluent people have always been doing whenever given unrestricted freedom. That's because they are better at using technology and finances and everything else.

Bitcoin was supposed to free money from financial institutions. But that's naive -- financial institutions have way more firepower and experience at subverting markets to their will.

The same goes for anything else. The larger the company the easier time it has to influence lawmaking, judicial, executive.

Maybe what we need is an equivalent of Butlerian Jihad but against organisations that are too big to be controlled.

I am waiting for delivery of my new iPhone. I am switching from Pixel 2 XL which looks brand new and is fully functional and does everything I need. There is literally not a single thing that I miss in this phone other than newer OS and updates.

I have been delaying this decision for a year, but as a professional I can not continue using a phone that is not regularly updated. And so I will switch to a platform that will allow me to keep the device alive for much longer.

Not sure why people decided to kill the parent post (confused by what flagging is for? We will never know...)

Anyway, it is exact same thing as the submission but actually caught on camera and posted on youtube.

I wouldn't say that is necessarily fault of Spring (though scope creep might be an important contributor).

I think the basic causes are:

1) Because most developers almost never need more than what you can find on Baeldung/Stack*. And even if they need, they need it for very small pieces of the application and the rest is just boilerplate.

2) Because you are penalised for customising the structure of your Spring application. You do that and you expose yourself to various complicated problems.

3) Because, frankly, Java is a bad programming language from the point of view of building abstractions. I would personally prefer to program applications in Common Lisp or even Clojure (or any other Lisp for that matter) if only for some reason these projects did not typically end in unmaintainable mess even well before Java projects do. It is truly tragic that Lisp and strong typing are fundamentally incompatible with each other.

There are different types of unmaintainable mess -- mess caused by copying and pasting stuff typically committed by novice developers who don't know any better tends to be infinitely easier to clean up than mess caused by "advanced" developers running amok with macros, continuations, generators and async callbacks.

4) Because developers are not taught how to structure their code. Nowadays getting something working is all that matters. And this is usually best accomplished by copying/pasting code blocks Lego-style from a dozen different tutorials. How anybody is going to learn to structure their large codebase if they never learned to structure a smaller one?

People who advance faster are the ones that are more efficient at copying pasting, not the ones that are better at writing better code.

In general case you would be right -- Spring does complicate things by hiding some of the actual references.

But reality is that most projects use very simple dependency injection rules. Most use just singleton beans and occasionally profiles for different environments (mostly to access external components like databases or APIs) and that is practically the extent of the problem.

Spring is flexible on paper. In reality (and very fortunately for me), most projects follow the examples and conventions you can find on the Internet. Which makes pretty much every Spring application look like any other Spring app, even if they don't have to.

By giving defined, recognisable structure to the application, Spring actually makes part of work easier. When I see controllers, repositories, services, etc., I usually know what I can expect.

Problems start when you find a project written by "smart" developers. These people are smart enough to write very complex structures and "customise" their Spring experience, but not smart enough to figure out they should separate app development from satisfying their intellectual curiosity.

My work in the past consisted mostly of dissecting and refactoring large legacy codebases. Usually after anybody who actually understood it already left and where the codebase is too large and rotten for anybody new to be able or willing to learn it.

I have my own process I apply for any change to code. The basic goal is to introduce zero defects to the code that I do not control/know. Which is crucial when I want to make thousands of changes to a huge application where if I make a mistake it can be very costly to the client, can cost me a huge amount of effort to fix and can completely undermine my effort.

Usually there is no good way to test the changes. I make hundreds or thousands of individual refactors, bundle them up and kind of hope I haven't broken anything in the process.

Some of these applications are just too large for one person to be able to comprehend. They either have vast user interfaces or vast network of integrations. That and no ability to test it in automated way.

This is the reasons why these applications usually aren't taken good care of -- new developers (new, not necessarily junior) are just too scared and unprepared to do anything than smallest changes and that with huge amount of effort.

From my experience, the programming language and environment plays enormous role in making this possible.

The most basic questions I may have when analysing the code I want to change are:

1) What is the thing I am looking at? For example, the exact type of variable, parameter, code for method, etc.

2) Where is the thing I am looking at referenced from? Usually when I want to modify a piece of badly written code, I have to be able to find and analyse every single usage of it.

3) When is the thing I am looking at being executed?

It is not just the ability to answer these questions -- I need to be able to answer them with absolute precision.

Since I program mostly Java, all that information is usually available to me. #3 is sometimes a little bit more tricky but if you can hunt all usages you can typically get to it with some effort.

But that is not the case for most programming languages these days. For example, I tried this with a large Python application and I have utterly failed and had to tell my client I can't help them. Which tells me that most programming languages are not suited to building large, complicated systems that somebody might want to be able to analyse and refactor in the future.

Main reasons for normal pixel arrays is that UI elements are built predominantly from vertical and horizontal lines. And that is enough to bury the idea of hex arrays until you have so many pixels that it doesn't matter anymore at which point there is no more advantages from hex arrays.

To the author of dead sibling comment: please, notify authorities for proper disposal and cleanup. Mercury contamination is extremely dangerous and can cause problems to your or other families for generations.

While small balls of Mercury might not seem dangerous, their continued presence means Mercury will slowly seep into environment over years and decades.

The key words are "under pure gravity loading" which means if there was no wind, earthquakes or occupants. These forces are more significant the higher the building. I wouldn't be surprised if including wind would halve the limit.

I also think they mean something that could be practically recognised as a building. You can build much higher if you are not restricted by a traditional proportions of a building (for example a pyramid or dome).

As to the building sinking -- it is not a difficult problem to solve. The reason some buildings face problem is that this is just a cost issue -- they guessed they need X amount of effort to provide stable base for the building and they guessed wrong. In practice there exists very simple algorithm to provide stable base -- drill to the rock face and use the underlying rock rather than possibly unstable ground. The reason this is not always used is because it can be very costly.

Then try to not make the modules too small?

Sure, if you were ready to make an entire separate application for it it will not be worse when you turn it into one package of a monolith?

Also you can build nested structures with modules (like a larger module consisting of smaller submodules).

Divide and conquer. This is how abstraction works in a nutshell. You start with a large problem, divide it into smaller parts (modules), each part you treat as a separate problem dividing it into smaller modules, and so on.

There exists no need to have a flat application consisting of hundreds of sibling modules.

An application might consist of larger modules, then some of those might have smaller submodules (packages), then those might have even smaller ones (classes), then you have methods, then you have statements, then you have function calls, etc.

A large monolith does not have to succumb to spaghetti or ravioli-type structuring. A good developer should know how to structure an application of any size.