This is the first in a series of articles I've decided to write that takes current controversial topics and looks at them with an unbiased, critical point of view by weighing up the claims and evidence (if any) that may exist out there. At the end, I will also give a run down of my personal views of the topics I talk about in these articles.
As I am sure you could have gathered from the title, this particular post is about Homeopathy.
What is Homeopathy exactly?
There seems to be a lot of misunderstanding as to what homeopathy actually is. People I have spoken to (family and friends) seem to misunderstand it, thinking it means natural or herbal remedies. While a lot of homeopathic remedies do purport to contain natural ingredients, a lot do not. So if homeopathy isn't about natural/herbal treatments, what is it? The easiest way to describe it is to go through the process a homeopathic remedy goes through to be prepared:
1. Identify the condition or affliction you wish to cure. Such as insomnia for example (of which there are many homeopathic remedies).
2. Find an active ingredient that would replicate the symptoms; in the case of insomnia, caffeine would replicate the symptom. This called the mother tincture (undiluted).
3. Dilute the active ingredient at a ratio of 1ml per 100ml. Thus creating a 1C solution as per homeopathic nomenclature.
4. Perform a process, known as succussion by homeopathic practitioners, which is supposed to activate the vital energy of the active ingredient. It involves a sequence of shaking and strikes against a surface.
5. Dilute this diluted, succussed liquid into another 100ml of water at the same ratio as the first dilution and perform succussion again. We now have a 1:1000 solution. In other words for every 1 molecule of the original active ingredient we have 1000 parts of water. This gives us a 2C solution to follow homeopathic nomenclature.
6. Continue this process again another 28 times until we arrive at a 30C solution, the recommended dilution according to the homeopathic founder Samuel Hahnemann. We now end up with a solution that is 10−60. Or in other words 1 part of active ingredient per 1060 of water.
To put that into perspective, "... a patient would need to consume 1041 pills (a billion times the mass of the Earth), or 1034 gallons of liquid remedy (10 billion times the volume of the Earth) to consume a single molecule of the original substance ..." as quoted from Wikipedia.
Why is it purported to work?
So with such a massive amount of dilution why are there so many people that believe it works? Putting aside the erroneous belief that homeopathy is about natural and/or herbal products, the following is how homeopathy is explained to work:
1. The act of succussion releases the active ingredients active energy into the water molecules which have the capacity to "remember" that energy, and the potency of that energy stored within the water molecules is enhanced with further dilutions and succussion.
2. That the electron makeup of the water molecules vibrate at the same frequency as the energy of the water molecules and therefore impart the benefits even with no active ingredient remaining.
There is also a lot of incidental evidence based on the reports from specific individuals that have claimed that they have suffered from a specific affliction that conventional medicines have been unable to cure but after using homeopathic remedies the symptoms and affliction have stopped. You can see people espousing such events on YouTube for example, and these isolated testimonies are often used as an indicator of its efficacy by homeopathic practitioners and those who believe in it.
The testimony of individual, isolated cases is not, however, a valid way to prove the efficacy of any medical treatment. There are just too many unaccounted for and uncontrolled variables to be able to truly determine if it was the homeopathic remedy that cured/alleviated the persons affliction or some other cause. Other possible causes that could be unaccounted for (and this is not a complete list, just what comes off the top of my head):
1. Environmental: Perhaps some aspect of the persons environment changed such as change of season (pollen, temperature, winds, etc) or they are no longer subjected to an external cause such as heavy metals, fungus', spores, etc.
2. Placebo Effect: A known medical phenomenon whereby a person given a treatment and told the treatment will help them feels an improvement even though the treatment was faked (sugar pill, fake surgery, etc). Essentially an anomaly produced by the mind that replicates the expected effects of the treatment had it been real.
3. Daily Habits: Perhaps the person started eating a healthier diet at the same time? Maybe they started an exercise regimen? Perhaps they shower more regularly, use a different route to work, or any number of possible alternatives...
It would also be good to mention that there are many individual, isolated cases where people have shown that homeopathic remedies do not work. These individuals will, for example, take an entire bottle full of homeopathic sleeping pills and show no effect.
What undeniable evidence exists to prove the claims?
I have hunted high and low for any studies by those for and against (and neutral) towards homeopathy. While there seem to be many studies that show homeopathy has no benefit besides that which a placebo would give you (such as this one, this one, this one, this one or even this one), I have yet to find any definitive studies that prove the efficacy of homeopathy greater than a placebo.
While I have read a number of studies that claim to provide undeniable evidence for the efficacy of homeopathy there have been numerous problems with these:
1. The study is not done in an isolated, lab environment and therefore cannot control for other possible effects correctly within statistical norms.
2. Population group of study participants are not randomised validly thereby biasing the end result (one study allowed the participants to choose whether they wanted to be treated with the homeopathic vs the conventional medicine which would bias the placebo effect).
3. The participants aren't limited in the affliction they suffer from, thereby introducing many unknowns into the study that cannot adequately be accounted for (one study used a group of cancer sufferers as the basis of its investigation but included around 10-15 different types of cancer sufferers).
4. Cherry picking of data. Some studies blatantly ignore any results that would show against homeopathy and only choose the results that show for homeopathy.
5. Comparisons of homeopathic treatments to invalid data sets. Some studies will take the results of the treatments and compare them to conventional medicine results from other sources such as other hospitals, or even results in of global averages instead of comparing with data retrieved from similar situations.
6. Separate groups are treated differently. One study had the homeopathic group also receiving additional care from medical staff where the "modern medicine" group did not receive this additional care. The improvement in quality of life of the participants would therefore be biased.
What would be undeniable evidence?
There is a very simple and logical method to attempt to prove the efficacy of any drug. A technique used all the time by pharmaceutical companies. It goes something like this:
1. Get together a large group of people. The more the better, but no less than say a couple hundred. These people need to all be suffering from the same affliction that your treatment/remedy is supposed to cure in relatively the same intensity if possible.
2. Split these people into two groups with roughly the same number in each group.
3. Tell both groups they will be given a remedy to help cure or alleviate the condition they suffer from.
4. Give only ONE group the actual remedy you want to test while giving the other group a placebo.
5. While the test is underway both groups are treated identically to not bring any bias into the results.
6. Measure the changes in participants over time from both groups by asking the same questions and doing the same tests.
After such a study you will now be able to compare both groups to each other. Seems reasonable to assume that if a remedy/treatment actually worked then the test group should show much better results than the control group. This setup also helps negate the placebo effect to some degree.
But that's not quite enough. This test would need to be done multiple times with different people. Preferably by different scientists as well to help negate any bias the experimenters may have.
To date, there have not been any such tests that prove the efficacy of homeopathy as a valid alternative treatment to modern medicine.
My personal view
I remain completely unconvinced. The first step, I feel, to proving homeopathy's efficacy as a viable medical treatment is to perform the kind of tests and studies as I have detailed above. Every other such study has proven it does no better than the placebo group but homeopathic practitioners cry foul of these studies.
The problem with the homeopathic "culture" is that it is also tends to make conspiratorial accusations. Claims against "Big Pharma" (whatever that is supposed to mean) try to denounce any studies that disprove homeopathy's effectiveness as attempts by the big pharmaceutical companies to protect their own profits. What doesn't seem to be factored in is that, if homeopathic remedies really did work, then the pharmaceutical companies would be the first ones to leap on it as a new revenue producer.
Speaking of big money, there are homeopathic suppliers which charge outrageous sums of money for these alternative and more "effective" remedies. Homeopathy is a big business, making a lot of money, out of peoples ignorance.
There are also the scientific issues to deal with. Those dilutions I talked about would essentially wipe out all possibility for even one molecule of the active ingredient to be present in a remedy. And once the dilution gets far enough, there will even be water molecules that have never came into contact with the original active ingredient. Apparently, it will inherit the "energy" or vibration of the ingredient from the water molecules carried over.
Homeopathic practitioners also will tell you that homeopathic remedies should be used in conjunction with conventional treatments. This serves very well to hide the lack of effect.
And lastly, the biggest reason I try to educate people on homeopathy, is that, unlike other pseudo-sciences like Astrology or the existence of Psychics, we are dealing with peoples health and well being here! People are using homeopathic remedies expecting to be cured and only end up delaying treatments that DO work or dying because there is an industry of quacks, peddling water, that claim it cures you when there is NO evidence it does!
Monday, November 28, 2011
Wednesday, November 23, 2011
Reading the article critically (i.e. properly)
Internet news sources are all fighting for readership, the more readers you have, the more advertising revenue you can generate. And therefore, so many of them now resort to linkbaiting tactics and misleading representation of data in order to "scare" people into reading their supposedly factual news article. The problem is also, that so many people just cannot seem to read between the lines to really see what a lot of these news reports are saying.
Lets take an example. I have just read an article by Juniper Networks about the rise of mobile malware. The title is the usual link-baiting, scare tactic fare; Mobile Malware Development Continues To Rise, Android Leads The Way. The article is here if you want to give it a quick once over. I'm going to cover the title first. Take the word "malware" out of that title (Mobile Development Continues To Rise, Android Leads The Way). Now we can all probably surmise thats true as well. More and more development is happening in the mobile space every day. More and more companies and software developers are jumping on the mobile bandwagon. And, in fact, Android is also leading the way there too. Android Market is having more new apps being developed for it than any other mobile application store.
And this is my first point. If you say X phenomenon is on the increase, you firstly need to determine if thats an anomaly based on the trend in the area it operates in. I don't have figures for this (because, wouldn't you know it, that article didn't give any), but this discussion isn't about proving the article, its about discussing the misleading way things are being reported.
For example, if all mobile application development is seeing an increase of 100%, and at the same time we are also seeing malware development increasing by the same 100%, well, that's not pointing to a unexpected increase in malware. All mobile apps are increasing by that amount. Its just a part of the curve.
What a lot of articles tend to do as well is throw "data" at a reader that make things look worse than they really are, and the use of "% increase from last year" is another popular tactic used. A lot of readers don't really seem to understand how that works. Using the linked Juniper article as an example, they make the claim:
And this practice continues throughout the article. All accurate data, just completely out of context and therefore ... useless!
But along with the use of out-of-context data, writers of these articles like to mix in other data which looks related but actually isn't. Here's an example from the piece:
So, the way they collect data about malware is by collecting the actual malware. Kind of like anti-virus software on a computer does it. What they don't mention in the article is that the increase in malware "collection" isn't only a factor of there actually being more malware. Its also a factor of improved methods of detecting and "collecting" them. Those are two very different trends which the article tries to bundle into one in order to help paint a scarier picture.
Readers should (must) read articles far more critically as there are innumerable tactics writers will use to find ways to make you click that link, become outraged at the content, and share it. When you eventually break it down, they are usually full of half truths and data taken out of context.
They find a way to lie by telling you the truth...
(And for the record, with regard to the example article itself, I don't think malware is not an issue on mobile devices, I just don't think its anywhere near as bad as Juniper paints it)
Lets take an example. I have just read an article by Juniper Networks about the rise of mobile malware. The title is the usual link-baiting, scare tactic fare; Mobile Malware Development Continues To Rise, Android Leads The Way. The article is here if you want to give it a quick once over. I'm going to cover the title first. Take the word "malware" out of that title (Mobile Development Continues To Rise, Android Leads The Way). Now we can all probably surmise thats true as well. More and more development is happening in the mobile space every day. More and more companies and software developers are jumping on the mobile bandwagon. And, in fact, Android is also leading the way there too. Android Market is having more new apps being developed for it than any other mobile application store.
And this is my first point. If you say X phenomenon is on the increase, you firstly need to determine if thats an anomaly based on the trend in the area it operates in. I don't have figures for this (because, wouldn't you know it, that article didn't give any), but this discussion isn't about proving the article, its about discussing the misleading way things are being reported.
For example, if all mobile application development is seeing an increase of 100%, and at the same time we are also seeing malware development increasing by the same 100%, well, that's not pointing to a unexpected increase in malware. All mobile apps are increasing by that amount. Its just a part of the curve.
What a lot of articles tend to do as well is throw "data" at a reader that make things look worse than they really are, and the use of "% increase from last year" is another popular tactic used. A lot of readers don't really seem to understand how that works. Using the linked Juniper article as an example, they make the claim:
A 472% increase in Android malware samples since July 2011.Ok. Thanks. But what was the actual number in July, 2011? If there were only 10 malware apps in July, that means now there are only 57.2. A tiny number compared to the vast number of non-malware applications. Why wouldn't they give you the real figures? I'm not privy to what they were thinking, but my first assumption is that the actual numbers are so low that it wouldn't be compelling reading, so they rather use the scarier 472%.
And this practice continues throughout the article. All accurate data, just completely out of context and therefore ... useless!
But along with the use of out-of-context data, writers of these articles like to mix in other data which looks related but actually isn't. Here's an example from the piece:
October showed a 110% increase in malware sample collection over the previous month and a striking 171% increase from what had been collected up to July 2011.
So, the way they collect data about malware is by collecting the actual malware. Kind of like anti-virus software on a computer does it. What they don't mention in the article is that the increase in malware "collection" isn't only a factor of there actually being more malware. Its also a factor of improved methods of detecting and "collecting" them. Those are two very different trends which the article tries to bundle into one in order to help paint a scarier picture.
Readers should (must) read articles far more critically as there are innumerable tactics writers will use to find ways to make you click that link, become outraged at the content, and share it. When you eventually break it down, they are usually full of half truths and data taken out of context.
They find a way to lie by telling you the truth...
(And for the record, with regard to the example article itself, I don't think malware is not an issue on mobile devices, I just don't think its anywhere near as bad as Juniper paints it)
Sunday, November 20, 2011
Thinking about your data model
Web applications are so much more than they used to be these days. With integrations into other web applications through exposed API's, the shifts to Single Sign On mechanisms, data sources that vary from the traditional database backends, no-sql solutions such as the Cassandra's out there and even flat files, the amount of data an application needs to process and be aware of is pretty intense.
And yet most web applications treat every data source except the local database as a second-class citizen. Even though those alternate data sources are critical to the running of the application, its only the database itself that is treated with abstraction within the application's model layer.
Model Layer? Well, any web developer attempting to build a web application in this day and age without the structure of some form of MVC (Model-View-Controller) architecture behind it is asking for a difficult time ahead. MVC imparts a fixed structure to a project with a very sensible separation of concerns in order to make your web application a more maintainable as well as extensible product. If you still work in the days of single files with HTML, business logic and data access all scrunched together, then you are woefully behind the best practices at the moment.
Unfortunately, a lot of the power of the MVC design pattern is diluted by misuse. Hell, I have even caught myself doing it at times. The one aspect I am discussing here is the model (or data) layer, which exists for the sole reason of being a central mechanism to allow you to grab the data you need for your application without having to worry about how that data is implemented, where it is stored, what the database architecture is, or even if its a database at all. And that last point is where things fall short.
A number of web apps I have seen (and BrandFu is not exempt from this unfortunately) will use the model layer exclusively for the applications own database. Any other data source is accessed ad hoc, and in varying ways, all throughout the application's controller and view layers and occasionally within the model but only to extend the abilities of grabbing rows out of the database. The problem with this method is that, if you ever want to decouple from a specific data source, such as a web service for example, and want to switch from consuming that web service to storing and managing that data on your own database, it will be a nightmare.
I am not saying I am not to blame either. I do get caught out with this myself. Developing BrandFu, we found ourselves occasionally making calls to external web service from outside the model layer. And a few weeks ago, we had some interest from a company who would like to have the service installed as a seperate instance over their own network to be able to provide BrandFu services to their own clients but on their own managed servers.
Sounds great but theres one problem. At SYNAQ we have an internally used "API" and Single Sign On (SSO) system called SASY. The BrandFu application itself relies quite heavily on SASY as a data source, but unfortunately for us, the web service requests are scattered around the code in the controller layer. Not all, but a fair number of them.
The solution? Replicate the object model returned from these existing API calls as pseudo-database tables in our symfony schema.yml file. Essentially, map the data returned from these API calls as if they were tables in our local database. symfony can then auto-generate the model classes for these API calls, exactly as it would in the more traditional database model, except we can then go ahead and create methods within these model classes that, instead of resulting in calls to our database, will make the API request to SASY, hydrate the object and send that back.
The result is that any chunk of code that needs that data doesn't know where it came from. It doesn't care. As long as it gets what it wants and can continue processing, why should it? This also encourages re-use a lot more, reduces code complexity, and makes maintenance even easier.
The other benefit, is that if we ever need to move away from an API-based data source for those "tables", well, their schema has already been defined and adding the bit of additional code to make a database query instead of a REST request is a lot simpler. You could even have support for both an API data source or a local database and switch between the two via config.
In fact, that's exactly I will be doing now. BrandFu is going to be transitioned to as clean a data model as possible over the next few weeks. This will simply make the application easier to maintain, easier to extend and easier to implement over a variety of systems and networks.
And yet most web applications treat every data source except the local database as a second-class citizen. Even though those alternate data sources are critical to the running of the application, its only the database itself that is treated with abstraction within the application's model layer.
Model Layer? Well, any web developer attempting to build a web application in this day and age without the structure of some form of MVC (Model-View-Controller) architecture behind it is asking for a difficult time ahead. MVC imparts a fixed structure to a project with a very sensible separation of concerns in order to make your web application a more maintainable as well as extensible product. If you still work in the days of single files with HTML, business logic and data access all scrunched together, then you are woefully behind the best practices at the moment.
Unfortunately, a lot of the power of the MVC design pattern is diluted by misuse. Hell, I have even caught myself doing it at times. The one aspect I am discussing here is the model (or data) layer, which exists for the sole reason of being a central mechanism to allow you to grab the data you need for your application without having to worry about how that data is implemented, where it is stored, what the database architecture is, or even if its a database at all. And that last point is where things fall short.
A number of web apps I have seen (and BrandFu is not exempt from this unfortunately) will use the model layer exclusively for the applications own database. Any other data source is accessed ad hoc, and in varying ways, all throughout the application's controller and view layers and occasionally within the model but only to extend the abilities of grabbing rows out of the database. The problem with this method is that, if you ever want to decouple from a specific data source, such as a web service for example, and want to switch from consuming that web service to storing and managing that data on your own database, it will be a nightmare.
I am not saying I am not to blame either. I do get caught out with this myself. Developing BrandFu, we found ourselves occasionally making calls to external web service from outside the model layer. And a few weeks ago, we had some interest from a company who would like to have the service installed as a seperate instance over their own network to be able to provide BrandFu services to their own clients but on their own managed servers.
Sounds great but theres one problem. At SYNAQ we have an internally used "API" and Single Sign On (SSO) system called SASY. The BrandFu application itself relies quite heavily on SASY as a data source, but unfortunately for us, the web service requests are scattered around the code in the controller layer. Not all, but a fair number of them.
The solution? Replicate the object model returned from these existing API calls as pseudo-database tables in our symfony schema.yml file. Essentially, map the data returned from these API calls as if they were tables in our local database. symfony can then auto-generate the model classes for these API calls, exactly as it would in the more traditional database model, except we can then go ahead and create methods within these model classes that, instead of resulting in calls to our database, will make the API request to SASY, hydrate the object and send that back.
The result is that any chunk of code that needs that data doesn't know where it came from. It doesn't care. As long as it gets what it wants and can continue processing, why should it? This also encourages re-use a lot more, reduces code complexity, and makes maintenance even easier.
The other benefit, is that if we ever need to move away from an API-based data source for those "tables", well, their schema has already been defined and adding the bit of additional code to make a database query instead of a REST request is a lot simpler. You could even have support for both an API data source or a local database and switch between the two via config.
In fact, that's exactly I will be doing now. BrandFu is going to be transitioned to as clean a data model as possible over the next few weeks. This will simply make the application easier to maintain, easier to extend and easier to implement over a variety of systems and networks.
Subscribe to:
Posts (Atom)