There are people who insist that they can hear the difference between 320kbps mp3s (using the highest-quality available compressor) and their uncompressed counterparts
So you can't? And hence you conclude no one can? Sorry, that is bullshit!
Science and math proves all of these things wrong, yet people still insist they're right.
A contrair! Sciense and math exactly proof that. You have a braindead idea about math and sciense. You can only hear up to like 20k Herz. But there are so called overtones, multiples of the base frequency. In this case 40k, 60k, 80k 100k etc. No human is able to hear 40k and above frequencies, but we all can hear if a 20k frequency is combined with an 40k overtone, or an 100k overtone even. Modern lossy compression algorithms cut off these overtones (as the overtone itself is unhearable)... nevertheless we can hear if it is 'there' or not.
You, again - quite clearly, claim that "Sciense and math exactly proof" that people can high quality compressed audio and uncompressed audio.
You then claim you can hear frequencies outside of the human range of hearing because they are "combined".
You do not seem to realize that you are, at this point, arguing that you can hear overtones through what you refer to as being "combined" but that compression algorithms cut off these overtones.
As per your usual method of discussing with people you insinuated that the person you were replying to was "braindead" (your other preferred term is "idiot".) I applied your own negative terms to you because you used the non-sensical "combined".
Reading all of your posts it is clear that English is not your first language and that you don't understand that when you talk to other people who are detail oriented that it isn't their responsibility to figure out what you meant to say but simply to deal with what you did say.
I did not say anything about mp3s.
You didn't say anything about hearing the differences between "320kbps mp3s (using the highest-quality available compressor) and their uncompressed counterparts"?
You argued, quite clearly, that it is because of overtones that you can tell the difference between 320kbps mp3s (using the highest-quality available compressor) and uncompressed audio.
Even you hear the difference between a simple 16kHz wave and one that is accompanied by a 32kHz and 48kHz overtone
Of course you do, and as usual, you're making an "idiot" out of yourself for everyone to see by claiming that you're hearing is "beyond human."
You DO hear when there's an overtone, but you don't hear the overtone, you hear the effect the overtone has on the audible range frequencies. See the "scientific facts" relating to destructive/constructive interference. This effect IS captured by the ADC, but can be filtered depending upon the overtone.
Your first post I answered to certailny was not clear about "abstracting away persistanve issues"
Are you an escaped inmate from a Guatemalan insane asylum?
The entire first post, including the title of the post, is explicitly about abstracting your persistence model.
"In other words, have your backend web services (presuming you're using them and not manually POSTing from a socket yourself to your own socket server) instantiate an instance of iMyDBAdapter and use it."
Maybe you don't find that clear, but that's because you apparently don't understand abstraction...
your naming examples like ValidateConnection or CheckConnection are certainly bad choices as an example.
The stupidity of your statement really cannot be overstated. You dislike ValidateConnection because you claim you will simply catch an exception when you connect; ergo, you are either connected or you are not. This, alone, is proof that you do not understand abstraction.
I'm a real programmer, not a manager.
And you'll apparently never get any further, because you'll need to understand abstraction before you can be an architect. I'm also not a programmer, I'm a software engineer (there's a difference that you're not aware of), a software architect, a founder, a co-founder, and I also perform technical due diligences for multiple Vencture Capital firms.
Abstracting away the fact that a Service is remote and not local leads to all forms of problems. It is very often. o good idea.
Actually, this is EXACTLY what you should abstract away. Yet again you demonstrate your lack of basic understanding of the purpose of abstraction. You think that abstracting away 'locality' is bad and leads to problems? Why on earth would it do that? LOL. Your abstraction layer should satisfy the requirements of the business logic, if locality is an issue (i.e. for performance) then your adapter implementation must account for that. The only time anyone using your abstraction layer should ever know anything about locality would be if that knowledge would be required so that the business logic could make a decision - otherwise, that sort of information should be encapsulated totally.
And no, I don't use that line often, actually I don't remember if I had used it already once.
Sure, I believe you, and you understand abstraction too.
Seriously, look at the reaction process for what you're talking about... you'll notice there is no reaction without adding oxygen... in the form of water.
Did you even bother to read the article you linked to? LOL. It clearly states that it oxidizes several metals. It then goes on to describe the reaction that you're trying to claim is the only oxidation case. In fact, the article you linked lists at least four chemical oxidations above and beyond those involving metals.
You seem to only capable of reading about the ones that have to do with water. Rather selective of you.
But hey, don't let basic chemistry stand in your way of looking silly.
Don't let basic reading skills stand in your way of looking silly [sic].
YOU CAN NOT OXIDIZE WITHOUT OXYGEN.
Yes, you can. The article you linked points this out to you as well.
LOOK AT THE DEFINITION OF OXIDIZE.
You appear to be obsessed with the colloquial definition of 'oxidize.' You should check out the formal definition; especially the part that relates it entirely to electron transfer.
Combustion is when something (rapidly) combines chemically with oxygen. Oxygen gas (molecules of two oxygen atoms) does not combust.
Yes, I'm guilty of very loosely (as in 'incorrectly') using the term combustion to describe the visual equivalent. I thought it would save me some time, it did not.;)
Using the term combustion was shortcut to avoiding discussing the details of highly oxygenated plasmas. BTW, oxygen plasmas are yellow, much like flames...
Funny, just a few years ago I was the chief software architect for a company purchased for more than 60 million dollars entirely for our enterprise product. One of the primary reason this company was acquired instead of its competitors was because we were pioneering open standards in our market verticals and supporting those open standards with public integration points that 3rd party companies, including our competitors, wrote integrations to.
This system had a persistence model that had to scale, not just horizontally, but in 'swim lane' fashion - or if you prefer the actual fashion we used, in AKF cube fashion. It handled tens of millions of persisted logic events daily and integrated with many different back end databases - all supported through this EXACT same facade/proxy system implemented with adapters. This pattern was used for all of the integration points and was how 3rd parties wrote integrations with our system.
So, whatever it is you do, you can rest assured that I write enterprise software in the "real world" and quite successfully.
You connect to a DB or open a File or open a Socket and either "it just works" or you get an exception.
You really just can't seem to understand abstraction.
After I answered to you, you suddenly talk about abstracting the business level.
Not at all. Again you demonstrate that you don't understand what abstraction is. By hiding the details of the persistence model, which means (so that you understand) that people using the abstraction interface don't know if it is a DB, or a file, or a web service, or a pipe, or a local process, or a remote process, the business logic simple deals with business objects.
If I was talking about abstracting the "business level" (presumably you mean business logic) I would be talking about an interface exposed to a view or consumer that didn't need to know any details about how the business logic operated. I was clearly not talking about that at all.
So either you made a mistake in choosing the right words or headline or you simply are mixing stuff up and now try to weasel out of it;D
I'm willing to bet that you end up in a lot of 'arguments' where you bring out this line. It's okay, maybe some day you'll get it.
Well, in the real world, when you abstract things properly you don't expose a "connect" method. The code behind your interface - the adapter - would use connect and disconnect internally.
In the real world, when you abstract things, you expose a method that validates that the persistence layer is functioning/configured/usable as a normal part of the application/service/component's life-cycle. I called it ValidateConnection in this scenario because of the way he described his issue.
No, you don't, there are plenty of things that burn without oxygen simply because there are lots of other oxidizers. Oxygen just happens to be the most common.
In any case, the combustion being referred to isn't "burning" it is the light emitted by the compressed gasses, and with oxygen being much more exciteable than nitrogen and their being the two most prevalent gases in this scenario, that's what I was referring to. This is what you see from a 'flame' in any case.
"...so that you simply write an adapter for pushing/pulling data" makes you think the abstraction layer would have the DB layout in?
Let me be perfectly clear then, the abstraction layer would simply know about the business logic side of things and that you can store and retrieve those things in some fashion most likely represented by some criteria associated with them.
If you simply talk about method signatures, then I wonder why you brought it up
I don't know what you mean.
And what exactly does ValidateConnection mean? Either you have a connection, or you have not, just an idea....
What? Who/what would already "have a connection" to another server or memory mapped file or process or socket?
ValidateConnection, in this example, would simply ensure that the backend persistence mechanism both exists and (as is required in most cases) that you have valid credentials.
Why would you be modeling anything relating to entities at the interface level?
iMyDatabase would have methods such as:
ValidateConnection GetSomething StoreSomething
It shouldn't know anything about how that data is stored, where it is stored, how your object is serialized/deserialized from a DB entity, et cetera...
The nitrogen under pressure remains inert, but the oxygen will combust at those levels. There's a great video of the plastic block they were testing with years ago with a huge wall of flame behind it as it traveled at mach 5 iirc...
I would have to agree about PostgreSQL, it is surprisingly flexible and powerful. I've used it for small business systems and recently on a 'big data' (oh, that overused buzzword...) project (millions of devices reporting dozens of times per day) and it has been fantastic.
...so that you simply write an adapter for pushing/pulling data.
Then you don't have to worry so much about making what appears to be an extremely premature optimization.
In other words, have your backend web services (presuming you're using them and not manually POSTing from a socket yourself to your own socket server) instantiate an instance of iMyDBAdapter and use it.
Later, when you find out that you actually do need MongoDB, PostgreSQL, sharded MariaDB, whatever, you can simply write another adapter class that simply has to satisfy the iMyDBAdapter interface.
The reason this works so well is that it will force you to separate your business logic from your underlying DB implementation (which requires a lot of discipline to do otherwise, especially when you just want to get something 'done'.)
Also, as another poster pointed out, you're much more likely to suffer from other issues relating to scaling (and issues better solved elsewhere) than a modern database.
My advice, stick rigidly to the interface/adapter mechanism and implement an adapter for whichever DB you're most comfortable with right now.
The irony is that Apple chose this action clearly because it was intuitive to its users which is highly suggestive that Apple themselves think it mimics common behavior (deadbolts, slide to unlock briefcases, chain locks, et cetera.)
They want to argue that it isn't obvious, but that people will find it obvious...;)
The iOS slide to unlock is not a physical counterpart for anything, it's a gesture.
Gestures don't have physical representations on the screen (although they occasionally have 'trails'.) The 'slide to unlock' does. You literally slide what appears to be a latch, incredibly similar to "slide to unlock" briefcases (which have been around for more than half a century.)
No human is able to hear 40k and above frequencies, but we all can hear if a 20k frequency is combined with an 40k overtone...
Talk about braindead in math and science. Surely you can calm down your rant and think objectively for one moment that sounds out of the range of human hearing cannot be heard by a human, and interference caused by sound outside the range of human hearing affects sound that IS in the range of human hearing. The result being that it is captured during conversion, and preserved based upon your compression methodology.
Slashdot Mirror
*that people can hear the difference between high quality compressed audio...
There are people who insist that they can hear the difference between 320kbps mp3s (using the highest-quality available compressor) and their uncompressed counterparts
So you can't? And hence you conclude no one can?
Sorry, that is bullshit!
Science and math proves all of these things wrong, yet people still insist they're right.
A contrair! Sciense and math exactly proof that. You have a braindead idea about math and sciense. ... nevertheless we can hear if it is 'there' or not.
You can only hear up to like 20k Herz.
But there are so called overtones, multiples of the base frequency. In this case 40k, 60k, 80k 100k etc.
No human is able to hear 40k and above frequencies, but we all can hear if a 20k frequency is combined with an 40k overtone, or an 100k overtone even. Modern lossy compression algorithms cut off these overtones (as the overtone itself is unhearable)
You, again - quite clearly, claim that "Sciense and math exactly proof" that people can high quality compressed audio and uncompressed audio.
You then claim you can hear frequencies outside of the human range of hearing because they are "combined".
You do not seem to realize that you are, at this point, arguing that you can hear overtones through what you refer to as being "combined" but that compression algorithms cut off these overtones.
As per your usual method of discussing with people you insinuated that the person you were replying to was "braindead" (your other preferred term is "idiot".) I applied your own negative terms to you because you used the non-sensical "combined".
Reading all of your posts it is clear that English is not your first language and that you don't understand that when you talk to other people who are detail oriented that it isn't their responsibility to figure out what you meant to say but simply to deal with what you did say.
I did not say anything about mp3s.
You didn't say anything about hearing the differences between "320kbps mp3s (using the highest-quality available compressor) and their uncompressed counterparts"?
Well, we know that isn't true.
And I told you that three or four times now.
Are you a crazy person?
Not agreeing with you at all.
You argued, quite clearly, that it is because of overtones that you can tell the difference between 320kbps mp3s (using the highest-quality available compressor) and uncompressed audio.
That's totally wrong.
Even you hear the difference between a simple 16kHz wave and one that is accompanied by a 32kHz and 48kHz overtone
Of course you do, and as usual, you're making an "idiot" out of yourself for everyone to see by claiming that you're hearing is "beyond human."
You DO hear when there's an overtone, but you don't hear the overtone, you hear the effect the overtone has on the audible range frequencies. See the "scientific facts" relating to destructive/constructive interference. This effect IS captured by the ADC, but can be filtered depending upon the overtone.
You can easily Google for it.
Last word, lol
Your talking about abstractions really makes not much sense, so I pray for the entroneurs you consult, good luck.
I'm sure it doesn't, because you have demonstrated quite clearly that you don't understand abstraction.
How can you be a competent architect when you don't understand abstraction? LOL.
In any case, you're a programmer, right?
Your first post I answered to certailny was not clear about "abstracting away persistanve issues"
Are you an escaped inmate from a Guatemalan insane asylum?
The entire first post, including the title of the post, is explicitly about abstracting your persistence model.
"In other words, have your backend web services (presuming you're using them and not manually POSTing from a socket yourself to your own socket server) instantiate an instance of iMyDBAdapter and use it."
Maybe you don't find that clear, but that's because you apparently don't understand abstraction...
your naming examples like ValidateConnection or CheckConnection are certainly bad choices as an example.
The stupidity of your statement really cannot be overstated. You dislike ValidateConnection because you claim you will simply catch an exception when you connect; ergo, you are either connected or you are not. This, alone, is proof that you do not understand abstraction.
I'm a real programmer, not a manager.
And you'll apparently never get any further, because you'll need to understand abstraction before you can be an architect. I'm also not a programmer, I'm a software engineer (there's a difference that you're not aware of), a software architect, a founder, a co-founder, and I also perform technical due diligences for multiple Vencture Capital firms.
Abstracting away the fact that a Service is remote and not local leads to all forms of problems. It is very often. o good idea.
Actually, this is EXACTLY what you should abstract away. Yet again you demonstrate your lack of basic understanding of the purpose of abstraction. You think that abstracting away 'locality' is bad and leads to problems? Why on earth would it do that? LOL. Your abstraction layer should satisfy the requirements of the business logic, if locality is an issue (i.e. for performance) then your adapter implementation must account for that. The only time anyone using your abstraction layer should ever know anything about locality would be if that knowledge would be required so that the business logic could make a decision - otherwise, that sort of information should be encapsulated totally.
And no, I don't use that line often, actually I don't remember if I had used it already once.
Sure, I believe you, and you understand abstraction too.
Well, the application I'm working on right now...
Great, I hope you have a competent architect.
Seriously, look at the reaction process for what you're talking about ... you'll notice there is no reaction without adding oxygen ... in the form of water.
Did you even bother to read the article you linked to? LOL. It clearly states that it oxidizes several metals. It then goes on to describe the reaction that you're trying to claim is the only oxidation case. In fact, the article you linked lists at least four chemical oxidations above and beyond those involving metals.
You seem to only capable of reading about the ones that have to do with water. Rather selective of you.
But hey, don't let basic chemistry stand in your way of looking silly.
Don't let basic reading skills stand in your way of looking silly [sic].
YOU CAN NOT OXIDIZE WITHOUT OXYGEN.
Yes, you can. The article you linked points this out to you as well.
LOOK AT THE DEFINITION OF OXIDIZE.
You appear to be obsessed with the colloquial definition of 'oxidize.' You should check out the formal definition; especially the part that relates it entirely to electron transfer.
See the stupid people who agree with me:
http://www.chemguide.co.uk/ino...
Don't just read the first part (the beginners' definition), read down to the "most important use of the terms oxidation" part...
Maybe I should have typed that in all caps so you could read it...
Oxygen doesn't do shit without fuel
I guess those electrochemists who study high pressure oxygen plasmas are a bunch of idiots...
Combustion is when something (rapidly) combines chemically with oxygen. Oxygen gas (molecules of two oxygen atoms) does not combust.
Yes, I'm guilty of very loosely (as in 'incorrectly') using the term combustion to describe the visual equivalent. I thought it would save me some time, it did not. ;)
Running shoes sounds 'optimistic' ;)...
Using the term combustion was shortcut to avoiding discussing the details of highly oxygenated plasmas. BTW, oxygen plasmas are yellow, much like flames...
You mean like Chlorine trifluoride? Lol...
Sorry, you have no idea about the real world.
Funny, just a few years ago I was the chief software architect for a company purchased for more than 60 million dollars entirely for our enterprise product. One of the primary reason this company was acquired instead of its competitors was because we were pioneering open standards in our market verticals and supporting those open standards with public integration points that 3rd party companies, including our competitors, wrote integrations to.
This system had a persistence model that had to scale, not just horizontally, but in 'swim lane' fashion - or if you prefer the actual fashion we used, in AKF cube fashion. It handled tens of millions of persisted logic events daily and integrated with many different back end databases - all supported through this EXACT same facade/proxy system implemented with adapters. This pattern was used for all of the integration points and was how 3rd parties wrote integrations with our system.
So, whatever it is you do, you can rest assured that I write enterprise software in the "real world" and quite successfully.
You connect to a DB or open a File or open a Socket and either "it just works" or you get an exception.
You really just can't seem to understand abstraction.
After I answered to you, you suddenly talk about abstracting the business level.
Not at all. Again you demonstrate that you don't understand what abstraction is. By hiding the details of the persistence model, which means (so that you understand) that people using the abstraction interface don't know if it is a DB, or a file, or a web service, or a pipe, or a local process, or a remote process, the business logic simple deals with business objects.
If I was talking about abstracting the "business level" (presumably you mean business logic) I would be talking about an interface exposed to a view or consumer that didn't need to know any details about how the business logic operated. I was clearly not talking about that at all.
So either you made a mistake in choosing the right words or headline or you simply are mixing stuff up and now try to weasel out of it ;D
I'm willing to bet that you end up in a lot of 'arguments' where you bring out this line. It's okay, maybe some day you'll get it.
Well, in the real world, when you abstract things properly you don't expose a "connect" method. The code behind your interface - the adapter - would use connect and disconnect internally.
In the real world, when you abstract things, you expose a method that validates that the persistence layer is functioning/configured/usable as a normal part of the application/service/component's life-cycle. I called it ValidateConnection in this scenario because of the way he described his issue.
No, you don't, there are plenty of things that burn without oxygen simply because there are lots of other oxidizers. Oxygen just happens to be the most common.
In any case, the combustion being referred to isn't "burning" it is the light emitted by the compressed gasses, and with oxygen being much more exciteable than nitrogen and their being the two most prevalent gases in this scenario, that's what I was referring to. This is what you see from a 'flame' in any case.
"...so that you simply write an adapter for pushing/pulling data" makes you think the abstraction layer would have the DB layout in?
Let me be perfectly clear then, the abstraction layer would simply know about the business logic side of things and that you can store and retrieve those things in some fashion most likely represented by some criteria associated with them.
If you simply talk about method signatures, then I wonder why you brought it up
I don't know what you mean.
And what exactly does ValidateConnection mean? Either you have a connection, or you have not, just an idea ....
What? Who/what would already "have a connection" to another server or memory mapped file or process or socket?
ValidateConnection, in this example, would simply ensure that the backend persistence mechanism both exists and (as is required in most cases) that you have valid credentials.
Why would you be modeling anything relating to entities at the interface level?
iMyDatabase would have methods such as:
ValidateConnection
GetSomething
StoreSomething
It shouldn't know anything about how that data is stored, where it is stored, how your object is serialized/deserialized from a DB entity, et cetera...
The nitrogen under pressure remains inert, but the oxygen will combust at those levels. There's a great video of the plastic block they were testing with years ago with a huge wall of flame behind it as it traveled at mach 5 iirc...
I would have to agree about PostgreSQL, it is surprisingly flexible and powerful. I've used it for small business systems and recently on a 'big data' (oh, that overused buzzword...) project (millions of devices reporting dozens of times per day) and it has been fantastic.
Wish I'd gotten on the bandwagon 10 years ago.
...so that you simply write an adapter for pushing/pulling data.
Then you don't have to worry so much about making what appears to be an extremely premature optimization.
In other words, have your backend web services (presuming you're using them and not manually POSTing from a socket yourself to your own socket server) instantiate an instance of iMyDBAdapter and use it.
Later, when you find out that you actually do need MongoDB, PostgreSQL, sharded MariaDB, whatever, you can simply write another adapter class that simply has to satisfy the iMyDBAdapter interface.
The reason this works so well is that it will force you to separate your business logic from your underlying DB implementation (which requires a lot of discipline to do otherwise, especially when you just want to get something 'done'.)
Also, as another poster pointed out, you're much more likely to suffer from other issues relating to scaling (and issues better solved elsewhere) than a modern database.
My advice, stick rigidly to the interface/adapter mechanism and implement an adapter for whichever DB you're most comfortable with right now.
The irony is that Apple chose this action clearly because it was intuitive to its users which is highly suggestive that Apple themselves think it mimics common behavior (deadbolts, slide to unlock briefcases, chain locks, et cetera.)
They want to argue that it isn't obvious, but that people will find it obvious... ;)
The iOS slide to unlock is not a physical counterpart for anything, it's a gesture.
Gestures don't have physical representations on the screen (although they occasionally have 'trails'.) The 'slide to unlock' does. You literally slide what appears to be a latch, incredibly similar to "slide to unlock" briefcases (which have been around for more than half a century.)
Thank you for pointing out the AC's idiocy... People think that interference YOU CAN HEAR wouldn't be captured... LOL.
No human is able to hear 40k and above frequencies, but we all can hear if a 20k frequency is combined with an 40k overtone...
Talk about braindead in math and science. Surely you can calm down your rant and think objectively for one moment that sounds out of the range of human hearing cannot be heard by a human, and interference caused by sound outside the range of human hearing affects sound that IS in the range of human hearing. The result being that it is captured during conversion, and preserved based upon your compression methodology.