For me, reusing widely used code that's heavily tested is preferable to the liability of handwritten code. If I'm given the opportunity, when possible, I'm going to choose the former.
That's a good default to start with, but that's not the whole story.
Every system has its own sets of constraints, and its own sets of goals. Those constraints and goals don't necessarily align with the assumptions made in the library you're using, because it's rare to have a library that does precisely what you need.
When you can't find a library that meets your needs, you have two choices: 1) roll your own solution, or 2) find a library that does something similar to what you want, and coerce the library into a form that suits your needs.
Neither are pleasant options, but I find #1 tends to give a better outcome in the long run. You know what your system constraints are, so you're in a better position to design around them.
I feel like the problem comes down to people not willing to read the docs. Reading the freaking manual helps understand if your tools are precise enough or configurable to solve your problems. Then reading the source code (if possible).
Then, assuming it’s still not worth extending, inventing it yourself isn’t such a bad idea.
On the other hand time required to read and _understand_ the source can be often very compareable to writing specific solution to your problem. Which all comes down to one biggest bottle neck of our industry: sharing understanding of solutions.
It needs to be a deliberate decision based on use cases. Depending on your business, it may be more valuable not to relinquish control of important functionality to third parties.
I suppose nobody really invents anything in-house in one sense. You reuse the hardware, the OS, the drivers, the network, cloud storage, IDE, source-control, JIRA, a programming language, several libraries, databases, at least one framework, and on top of all that you may have some sprinkles that are "your application."
I think the question is always, how smart an engineer can you be to reuse the maximal amount possible to deliver a good experience quickly.
React is a view library. It keeps the page to date with your data, much like Vue or Angular.
jQuery is a DOM manipulation library, so in a sense it is lower level than React. It abstracts the DOM implementations across browsers to provide a unified interface. It lets you do things like animations, and find element dimensions in a cross-browser way.
Today, developers are choosing React because it more closely aligns with the needs of modern webapps. Most browsers have become more standards-compliant so jQuery is not such a necessity anymore. React is a fast and readable library to keep your page up to date with your data.
> Any slack present in the string winding can cause the string to go out of tune easily if you loosen the string to the correct tension.
You can get around that by using harmonics. Because you play harmonics without pushing all the way down, you can achieve a more precise tune.
The strongest harmonic is achieved when you gently place your finger on the string directly over the metal fret. A harmonic can only be achieved when you do not press the string all the way down into the fret.
The harmonic on the 7th fret of one string is the same note as the harmonic on the 5th fret on the next higher string. This is true for all consecutive string pairs other than (G, B).
You can tune using these pairs of harmonics to tune more precisely than pressing all the way down.
You will need to tune the (G, B) pair without harmonics.
You're correct but I think you are addressing a different problem. He was mentioning the issue specifically about differences in tension from turning the peg clockwise versus counter clockwise.
If you tune downard tonaly, so from an F# and you want an F, the string will more easily fall out of tune. I am not sure what causes this, some interplay between the friction of the peg and the final resting position of the string on the nut being different depending on the direction maybe. By tuning down perhaps you end up relying on some of the friction from the nut which goes away quickly as the string settles to an equal tension on either side of the nut.
I have noticed it's not as much of an issue on carbon nuts or well made nylon/bone nuts.
> You can get around that by using harmonics. Because you play harmonics without pushing all the way down, you can achieve a more precise tune.
The big problem with trying to tune a guitar that way is that you're tuning a guitar so it's in tune when you don't press the strings, but then when you actually play it you do press down the strings. Strings 5 and 6 should be tuned slightly flat relative to the first four, the exact amount depends on your play style, but if you don't tune them a bit flat then they'll sound sharp when you're playing. If you haven't tried this yourself you might guess that it's subtle effect, but depending on your play style it can be huge.
The other problem is that the harmonics are actually 2 cents off of an equal tempered fifth, and if you tune six strings that way you'll end up 10 cents off. Your octaves will sound wrong.
> The big problem with trying to tune a guitar that way is that you're tuning a guitar so it's in tune when you don't press the strings, but then when you actually play it you do press down the strings.
When you press the strings, they will all press equally, playing a correct relative tune.
I have never been able to consistently tune a guitar using harmonics. It was always a fun trick when I was first learning to play, but it was never quite right and now that I'm older it is far more difficult to hear subtle differences between harmonics.
It's been quite a while since I tuned a guitar this way, but isn't the trick with using harmonics that you listen for clearly audible "beats" when it gets in the ballpark? Once there are no more audible"beats" you're in tune.
Hearing loss has no impact on this - unless it's really, really bad, of course.
That would definitely get you close, but the range that the "beats" are not audible is a wide range and in my experience hearing loss had affected my ability to detect their absence.
The article is short and cursory. It can be summarized with the following excerpt:
> Zcash uses zero-knowledge proofs to guarantee that transactions are valid despite the fact that information about the sender, the recipient, and the amount transacted all remain hidden. The power of the idea has major banks interested. JPMorgan Chase recently worked with Zcash to add zero-knowledge functionality to its own private Ethereum-based blockchain.
> Fulcrum. Given a sequence of integers, returns the index i that minimizes |sum(seq[..i]) - sum(seq[i..])|. Does this in O(n) time and O(n) memory.
This is doable in O(n) time and O(1) memory. Sum the list once. Then start from the beginning, collecting a running total and subtracting from the sum for a running difference.
The surveillance AI knows nothing of the difference between malum in se (crime!) and malum prohibitum ("crime"). The pamphleteer protesting local corruption and the strongarm robber are caught in the same trap.
jQuery's bread and butter is DOM manipulation. However, for even moderately small use cases (even an interactive form) it is useful to use React, Angular, or some data binding framework, as state changes in jQuery quickly become unmaintainable.
It _can_ become unmaintainable but it entirely depends on how you define your view state, you can still create large applications with jquery if you refrain from creating overly complex state UI (speaking from experience). One thing I find overly shunned in favour of heavy MVC is CSS, CSS is a bloody state machine, it's perfect to manage your UI, you need one DOM call to update one piece of state... define the reset in CSS and your MVC UI component suddenly seem over engineered.
