Re:I noticed the lack of theory in the ToC
on
Head First SQL
·
· Score: 1
There is a second point too that I suppose I should have addressed. That is that often organizations have trouble designing software because personal preferences get in the way of solid engineering. How many times do you hear "we have to use XML!" or some other technology solely because it is hot and not because it is useful? Consequently a lot of design time ends up being poorly used because engineers are trying to add things to placate management rather than remove things to make the design more maintainable.
BTW, one of my latest approaches is a methodology I call SODA (Service Oriented Database Architecture), which suggests that the object model of the application and the relational database should be designed as a loosely coupled system, connected discoverable stored procedures which can be semantically integrated into the object models. This way your relational design is only loosely coupled to your object structures, but the data manipulation logic is re-usable with other applications, and so forth. Think of an ORM which does procedureprocedure rather than data structure mapping. It also ensures only a loose coupling between logical and physical programming structures. (Of course as with all tools, it is not to be used everywhere-- it is only useful in solving the O-R Impedance Mismatch.) However, I am still developing best practices for this approach....
However, an approach like SODA allows you to forget about the needs of the application temporarily and focus on good DB design, and then later create a robust business logic interface between the application and the db which can be re-used in other applications (even if they are in other languages). It also allows for easier app development because the object interface largely becomes a lighter-weight automation mechanism.
Re:I noticed the lack of theory in the ToC
on
Head First SQL
·
· Score: 3, Insightful
IMO that sort of thinking is a mistake. It actually comes from the desire to cut down on planning time because management sees it as dead weight. And worse, people designing databases who have no clue what they are doing mathematically speaking.
In general, I have found that every hour of planning time spent tends to eliminate up to 10 hours of coding, and often as much as 100 hours of pre- and post-release re-engineering and bug fixing.
The goal ought to be to optimize time and expenses across the entire software lifecycle rather than cutting down on the most important places where time gets spent (on the design). This generally means spending more time on design, less on buzzword-compliance, and less on actual coding. If you do it right, testing and debugging effort go *down* as well.
Instead people end up with bloated monstrosities when better-designed products could have been built with less time an money.
Re:Well, you have to start somewhere
on
Head First SQL
·
· Score: 1
Actually, I think that Codd made a few mistakes as well in the relational model. While these seem like minor mistakes and should be put in the perspective of the fact that Codd founded the field (so of course there were going to be some oversights that need to be addressed later), they haunt the industry to this day. Chief among them is the definition of NULL which introduces semantic ambiguity into databases.
For the most part, SQL is an imperfect approach at writing relational algebra in plain English. So just because the databases of today are not perfect implementations of relational math doesn't mean that they don't follow the relational model.
Re:I noticed the lack of theory in the ToC
on
Head First SQL
·
· Score: 1
In that case, if you want to drive a database, not build it, leave out the bit about DDL (create table and such). Stick with SELECT, INSERT, UPDATE, and DELETE operations (the DML statements). Include a sample database that people can practice with.
If you want to cover the DDL, then you are teaching people how to build it and theory is therefore a good thing!
Also, I am not sure that summary data always means denormalization. Normalization definitions in relational algebra doesn't seem to address questions of values which could be calculated from other values in a set (except where functional dependency is an issue) though obviously good engineering practices would keep these at a minimum.
For example, suppose we have an accounting application which accepts hundreds of thousands of invoices per year. After 10 years, we want to go find the balance of one business checking account. Processing an aggregate over ten years and millions of invoices is likely to be inadequate to the business need.
In that case, my proposed solution is to have summary data at checkpoints. I.e. "last time you closed your books, the balance was $x." Now we still have to run an aggregate but it is only an average of six months data, and most of that is probably clustered together on disk. This is an atomic fact, it does not overly complicate data management, and it is a heck of a lot better than trying to keep a summary table up to date.
However, I think that projects should try to position their official site as the primary point of distribution (i.e. have the project actually manage getting packages for main distros up), and control main distribution points through the project. This doesn't mean you can control secondary distribution points, but it does mean you should try to influence and coordinate the distribution channels so that new updates get pushed out fast.
This is a major issue with licenses like Mr Rosen's OSL and the AGPL. Forced distribution makes it more difficult to protect your trademark and ensure that people are getting the most secure versions from you.
First, a lot of the negative banter comes from those of us who do database engineering and understand how technical of a field it is. Of course, if it is limited to MySQL, this is not a big issue because you can't do proper db design on MySQL anyway.
I guess my feeling is that it would be great if beginner books at least discussed theory, at least in appendix. I.e. "Here is the basis of how this works, and here is where you can go to get more information" or "Here are a few known challenges you may run into. Here is where you can go to get more information."
However the fact is that no beginner books do this, which means that those of us who do the engineering end up doing a lot of unnecessary cleanup. We all know you have to start somewhere, but it would be nice to have somewhere *good* to start.
The problem is that relational databases are built around a very specific mathematical model. If you don't understand the principles of RDBMS's and at least have a basic clue about the math behind them, you will never be able to use them effectively.
Most of the time, a lot of us end up having to clean up databases designed by programmers. A lot of the time, the programmers don't really grasp the problems inherent in ignoring the O-R Impedance Mismatch issues and so we have a lot of horrid databases out there.
Having said this, one does have to start somewhere. All I would ask from a beginner book is at least to provide notes about the advanced topics so that people know where to look. Yet this book seems extremely light on theory (no real discussion of what the normal forms actually mean from a relational math perspective).
Yes, you should have a reasonable grasp of at least algebra to design databases. Yes, authors should be unafraid to use terms like "functional dependency" and "transitive functional dependency." Let is stop pretending that RDBMS's are anything other than math engines.
Well, you have to start somewhere
on
Head First SQL
·
· Score: 1
We learn by doing but we can't do unless we understand the syntax.
Additionally, I would highly recommend Codd's Papers, and CJ Date's books on the subject. These will help to provide a theoretical framework for understanding what an RDBMS is all about.
Re:Don't get in over your head...
on
Head First SQL
·
· Score: 1
Where the trick comes in is designing the database so that the types of queries you will be running against it take the least time. There are times and places where you need to create a means to "run this specific query really fast" and in that case, good relational design is not a major issue. Nothing runs faster than a sequential scan over a summary table containing the exact results you want to obtain.
However, when you do this, you prejudice all other queries. Many queries may take far longer to run, or may not be possible at all.
IMO, good, highly normalized database design is a prerequisite for good long-term performance (unless you are running MySQL-- then the planner may choke on your queries;-) ). You can then increase performance using various tricks (indexes, for example) to help specific queries spend less time filtering through unwanted information.
So far, I have almost always found heavily normalized designs are almost always a technical win when looking at future needs etc.
Note I am talking about normalization as a mathematical process based on data domains, functional dependencies, etc. This means building a database which is mathematically and semantically solid rather than working on program requirements (i.e. the structure of the data in the db should *not* be based on the program's data structures but rather on the inherent internal structure of the information).
I noticed the lack of theory in the ToC
on
Head First SQL
·
· Score: 1
Basically, it covers some basics of normalization, but no real background about the concepts or RDBMS's. IMO, one needs to cover, at very least, the fundamental concepts of relational math, and the mathematical definitions of SVD, FD's, MVD's, and the normal forms. Otherwise the book is actually teaching people to use RDBMS's wrong (MySQL is great at doing this too, so it is no surprise).
Basically the AGPL and GPL v3 both allow the use of components under the other license without affecting the license of the whole work. Hence it seems to me that if you release an AGPL v3 library, nothing prevents me from writing all network interfaces with GPL v3 code, hence absolving myself from the requirements. Similarly, nothing prevents me from writing all user interfaces in GPL v3 code, thus opting out of the AGPL restriction.
And even when I am required to make the changes to the core libraries back, nothing prevents me from writing another library which implement that functionality, so all you get is a note stating that functionality is in another library which is not distributed.
Again, I think that forced distribution is an anathema to software freedom and would never use this license anyway, even if that forced distribution does not force a distribution of the code implementing new functionality.
Not necessarily. The GPL v3 compatibility clause specifically states that the AGPL additional requirements do not extend to GPL v3 portions of the work.
Because both licenses have special compatibility clauses, they are legally compatible. However, I agree that they are not compatible in spirit.
Personally, I think that licenses which require the distribution of source for publcially accessible services are problematic to projects anyway because they reduce the ability of the core team to be *the* authoritative point of distribution for the most up to date versions. (Yes, the GPL undermines this to some extent too but it is different because if you distribute GPL software, you probably know to check back with the core team frequently.) This means that a project may contend with the fact that a very large percentage of distribution could remain on old versions (possibly with security vulnerabilities corrected in the official version) and users are arguably unlikely to know the difference.
Personally, I would never ue the AGPL and tend to steer clear of AGPL projects, but then I am still a fan of the GPL v2.
Also the AGPL v3 has a major issue inherited from the GPL v3. Section 7 is extremely broadly worded and reasonable readings could easily conclude that permissive licenses such as the BSD, ISC, and MIT licenses would be incompatible (because the GPL v3 could be read as to require conversions of these licenses to ones with all the restrictions of the GPL v3-- see paragraphs 2 and 4 of section 7). Because the general consensus is that permissive licenses don't allow license changes on mere distribution of verbatim copies, this poses a problem of interpretation. I have heard one lawyer from the SFLC argue that this is not a problem because the additional permissions inherent in permissive licenses don't meet the definition of additional terms in paragraph 1 of section 7, but until there is a widely accepted public document which states this I think it is dangerous for any project to assume that these licenses are compatible without legal help in preparing additional interpretive information to be distributed with the license. (IANAL, TINLA, etc.)
I don't know. If you just have a web site using Drupal, do your modifications count as private? I.e. are you just required to make the sources available to yourself? Obviously if you were hosting Drupal for others that would be different.
Note that this license like the GPL v3 is very vague on a number of points. The largest ones have to do with license compatibility, but this clause is not clear either.
I don't know. It seems to me that whoever did the triage screwed up. This is not unusual. I remember working at Microsoft and running into issues getting a number of issues fixed. However, the organizational structure of the company often makes it impossible to get problems fixed because nobody wants to act as a cost center for the security (passing the buck).
When I worked at Microsoft, I remported what I felt was a serious security flaw. Despite the fact that the exploit I remorted resulted in one of the lead engineers handing me his Hotmail password, this was seen as a user issue and not a security one (it had to do with options for encoding URL's so that the @ sign could be sufficiently obfuscated that nobody could be expected to see what was going on), that is, until a few months later when someone sent out phishing emails appearing to come from Microsoft. (It was then fixed in a hurry).
I have had other experiences at Microsoft suggesting that only when it becomes a PR problem for Microsoft will they fix something which does not fit their ideas of how the software is supposed to be used. Their answer in this case suggests that the feeling is that the solution is not to use untrusted sources of Access dbs. Just wait for someone in a business to show how this can be done using Access with far fewer permissions, and then it might get fixed.
First of all, the links are not permanent and are more fragile because now you have 2 sources of failures rather than one (tinyurl could go down, as could the server you really want to reach). Hence it is certainly bad practice to use something like tinyurl for something which needs permanence and transparency.
However, I will agree that it is not going to damage the internet as we know it. If TinyURL becomes corrupt, shuts down, gets hacked, whatever, it is going to damage the users of the service and show them why this is a bad idea. However I don't see us becoming so dependant on these services that such damage can be said to cause serious problems for the internet as a whole.
BTW, one of the interesting uses I have for tinyurl is testing XSS vulnerabilities in web apps, especially when attacking limited-length fields. Oftne you can fit a script tag with a source attribte into a field using tinyurl that you can't using the full path. In addition to the legitimate testing angle, this also leads to issues of attackers using the service for the same purpose.
If you remember the pied piper story, it ended with the piper leading all the children of the town away to the mountain, where it closed after them. If it can be done with pests, are you saying we should think about the possibility it can be done with children too?
The idea is quite simple. They thought that Napster was a few bad apples stealing from them (please, don't attack me for saying this-- I am not agreeing with them, just saying what I think they believed). So they sued Napster, and similar services popped up.
The problem with organizational inertia is that it tends to build, and this was an unseen slippery slope. Pretty soon they found things had gone way out of control and pretty soon we see all out war with consumers (which has still not begun to abate despite these statements).
The war was inadvertently started when the Napster lawsuit was filed, in the same way that WWI was inadvertently started when Archduke Ferdinand embarked on his visit to Sarajevo.
You are aware that General Howe wrote in his diary about his sympathies for the colonists, right? Most of the other British Generals know, respected, and sympathized with the economic and political injustices in the colonies (Burgoyne was an exception and note that Howe withheld military support for Burgoyne against direct orders from the crown).
In the American revolution there were two sides: The British Crown, and almost everyone in the colonies (British military included). Believe it or not it was fought as a gentleman's war on both sides (Washington making arrangements with Howe to return captured Masonic regalia, for example).
The real cause of the American revolution was simple. British subjects in the American colonies were being denied basic political and economic rights which were afforded British subjects living in England. These included a right to trial by jury, a right to be represented in tax decisions, various economic controls, and the like. The Declaration of Independence documents these problems well (and seems particularly relevant today under the Administration of President George III). And the Bill of Rights, with a few exception, is based largely on the rights that British subjects in England were granted.
I would give up my right to vote for one election for enough money to make a strong and credible run as an independant candidate for the office of President. If it looked like I would lose anyway, I would back out and endorse the candidate I favored. This would make that money have a lot more impact than a single vote.
THe right to vote is not the same as the right to participate in the political system.
Slashdot Mirror
There is a second point too that I suppose I should have addressed. That is that often organizations have trouble designing software because personal preferences get in the way of solid engineering. How many times do you hear "we have to use XML!" or some other technology solely because it is hot and not because it is useful? Consequently a lot of design time ends up being poorly used because engineers are trying to add things to placate management rather than remove things to make the design more maintainable.
BTW, one of my latest approaches is a methodology I call SODA (Service Oriented Database Architecture), which suggests that the object model of the application and the relational database should be designed as a loosely coupled system, connected discoverable stored procedures which can be semantically integrated into the object models. This way your relational design is only loosely coupled to your object structures, but the data manipulation logic is re-usable with other applications, and so forth. Think of an ORM which does procedureprocedure rather than data structure mapping. It also ensures only a loose coupling between logical and physical programming structures. (Of course as with all tools, it is not to be used everywhere-- it is only useful in solving the O-R Impedance Mismatch.) However, I am still developing best practices for this approach....
However, an approach like SODA allows you to forget about the needs of the application temporarily and focus on good DB design, and then later create a robust business logic interface between the application and the db which can be re-used in other applications (even if they are in other languages). It also allows for easier app development because the object interface largely becomes a lighter-weight automation mechanism.
IMO that sort of thinking is a mistake. It actually comes from the desire to cut down on planning time because management sees it as dead weight. And worse, people designing databases who have no clue what they are doing mathematically speaking.
In general, I have found that every hour of planning time spent tends to eliminate up to 10 hours of coding, and often as much as 100 hours of pre- and post-release re-engineering and bug fixing.
The goal ought to be to optimize time and expenses across the entire software lifecycle rather than cutting down on the most important places where time gets spent (on the design). This generally means spending more time on design, less on buzzword-compliance, and less on actual coding. If you do it right, testing and debugging effort go *down* as well.
Instead people end up with bloated monstrosities when better-designed products could have been built with less time an money.
Actually, I think that Codd made a few mistakes as well in the relational model. While these seem like minor mistakes and should be put in the perspective of the fact that Codd founded the field (so of course there were going to be some oversights that need to be addressed later), they haunt the industry to this day. Chief among them is the definition of NULL which introduces semantic ambiguity into databases.
For the most part, SQL is an imperfect approach at writing relational algebra in plain English. So just because the databases of today are not perfect implementations of relational math doesn't mean that they don't follow the relational model.
In that case, if you want to drive a database, not build it, leave out the bit about DDL (create table and such). Stick with SELECT, INSERT, UPDATE, and DELETE operations (the DML statements). Include a sample database that people can practice with.
If you want to cover the DDL, then you are teaching people how to build it and theory is therefore a good thing!
Also, I am not sure that summary data always means denormalization. Normalization definitions in relational algebra doesn't seem to address questions of values which could be calculated from other values in a set (except where functional dependency is an issue) though obviously good engineering practices would keep these at a minimum.
For example, suppose we have an accounting application which accepts hundreds of thousands of invoices per year. After 10 years, we want to go find the balance of one business checking account. Processing an aggregate over ten years and millions of invoices is likely to be inadequate to the business need.
In that case, my proposed solution is to have summary data at checkpoints. I.e. "last time you closed your books, the balance was $x." Now we still have to run an aggregate but it is only an average of six months data, and most of that is probably clustered together on disk. This is an atomic fact, it does not overly complicate data management, and it is a heck of a lot better than trying to keep a summary table up to date.
over distribution.
However, I think that projects should try to position their official site as the primary point of distribution (i.e. have the project actually manage getting packages for main distros up), and control main distribution points through the project. This doesn't mean you can control secondary distribution points, but it does mean you should try to influence and coordinate the distribution channels so that new updates get pushed out fast.
This is a major issue with licenses like Mr Rosen's OSL and the AGPL. Forced distribution makes it more difficult to protect your trademark and ensure that people are getting the most secure versions from you.
First, a lot of the negative banter comes from those of us who do database engineering and understand how technical of a field it is. Of course, if it is limited to MySQL, this is not a big issue because you can't do proper db design on MySQL anyway.
I guess my feeling is that it would be great if beginner books at least discussed theory, at least in appendix. I.e. "Here is the basis of how this works, and here is where you can go to get more information" or "Here are a few known challenges you may run into. Here is where you can go to get more information."
However the fact is that no beginner books do this, which means that those of us who do the engineering end up doing a lot of unnecessary cleanup. We all know you have to start somewhere, but it would be nice to have somewhere *good* to start.
The problem is that relational databases are built around a very specific mathematical model. If you don't understand the principles of RDBMS's and at least have a basic clue about the math behind them, you will never be able to use them effectively.
Most of the time, a lot of us end up having to clean up databases designed by programmers. A lot of the time, the programmers don't really grasp the problems inherent in ignoring the O-R Impedance Mismatch issues and so we have a lot of horrid databases out there.
Having said this, one does have to start somewhere. All I would ask from a beginner book is at least to provide notes about the advanced topics so that people know where to look. Yet this book seems extremely light on theory (no real discussion of what the normal forms actually mean from a relational math perspective).
Yes, you should have a reasonable grasp of at least algebra to design databases. Yes, authors should be unafraid to use terms like "functional dependency" and "transitive functional dependency." Let is stop pretending that RDBMS's are anything other than math engines.
We learn by doing but we can't do unless we understand the syntax.
Additionally, I would highly recommend Codd's Papers, and CJ Date's books on the subject. These will help to provide a theoretical framework for understanding what an RDBMS is all about.
However, when you do this, you prejudice all other queries. Many queries may take far longer to run, or may not be possible at all.
IMO, good, highly normalized database design is a prerequisite for good long-term performance (unless you are running MySQL-- then the planner may choke on your queries
So far, I have almost always found heavily normalized designs are almost always a technical win when looking at future needs etc.
Note I am talking about normalization as a mathematical process based on data domains, functional dependencies, etc. This means building a database which is mathematically and semantically solid rather than working on program requirements (i.e. the structure of the data in the db should *not* be based on the program's data structures but rather on the inherent internal structure of the information).
Basically, it covers some basics of normalization, but no real background about the concepts or RDBMS's. IMO, one needs to cover, at very least, the fundamental concepts of relational math, and the mathematical definitions of SVD, FD's, MVD's, and the normal forms. Otherwise the book is actually teaching people to use RDBMS's wrong (MySQL is great at doing this too, so it is no surprise).
in the AGPL.
Basically the AGPL and GPL v3 both allow the use of components under the other license without affecting the license of the whole work. Hence it seems to me that if you release an AGPL v3 library, nothing prevents me from writing all network interfaces with GPL v3 code, hence absolving myself from the requirements. Similarly, nothing prevents me from writing all user interfaces in GPL v3 code, thus opting out of the AGPL restriction.
And even when I am required to make the changes to the core libraries back, nothing prevents me from writing another library which implement that functionality, so all you get is a note stating that functionality is in another library which is not distributed.
Again, I think that forced distribution is an anathema to software freedom and would never use this license anyway, even if that forced distribution does not force a distribution of the code implementing new functionality.
Not necessarily. The GPL v3 compatibility clause specifically states that the AGPL additional requirements do not extend to GPL v3 portions of the work.
Because both licenses have special compatibility clauses, they are legally compatible. However, I agree that they are not compatible in spirit.
Personally, I think that licenses which require the distribution of source for publcially accessible services are problematic to projects anyway because they reduce the ability of the core team to be *the* authoritative point of distribution for the most up to date versions. (Yes, the GPL undermines this to some extent too but it is different because if you distribute GPL software, you probably know to check back with the core team frequently.) This means that a project may contend with the fact that a very large percentage of distribution could remain on old versions (possibly with security vulnerabilities corrected in the official version) and users are arguably unlikely to know the difference.
Personally, I would never ue the AGPL and tend to steer clear of AGPL projects, but then I am still a fan of the GPL v2.
Also the AGPL v3 has a major issue inherited from the GPL v3. Section 7 is extremely broadly worded and reasonable readings could easily conclude that permissive licenses such as the BSD, ISC, and MIT licenses would be incompatible (because the GPL v3 could be read as to require conversions of these licenses to ones with all the restrictions of the GPL v3-- see paragraphs 2 and 4 of section 7). Because the general consensus is that permissive licenses don't allow license changes on mere distribution of verbatim copies, this poses a problem of interpretation. I have heard one lawyer from the SFLC argue that this is not a problem because the additional permissions inherent in permissive licenses don't meet the definition of additional terms in paragraph 1 of section 7, but until there is a widely accepted public document which states this I think it is dangerous for any project to assume that these licenses are compatible without legal help in preparing additional interpretive information to be distributed with the license. (IANAL, TINLA, etc.)
I don't know. If you just have a web site using Drupal, do your modifications count as private? I.e. are you just required to make the sources available to yourself? Obviously if you were hosting Drupal for others that would be different.
Note that this license like the GPL v3 is very vague on a number of points. The largest ones have to do with license compatibility, but this clause is not clear either.
I don't know. It seems to me that whoever did the triage screwed up. This is not unusual. I remember working at Microsoft and running into issues getting a number of issues fixed. However, the organizational structure of the company often makes it impossible to get problems fixed because nobody wants to act as a cost center for the security (passing the buck).
When I worked at Microsoft, I remported what I felt was a serious security flaw. Despite the fact that the exploit I remorted resulted in one of the lead engineers handing me his Hotmail password, this was seen as a user issue and not a security one (it had to do with options for encoding URL's so that the @ sign could be sufficiently obfuscated that nobody could be expected to see what was going on), that is, until a few months later when someone sent out phishing emails appearing to come from Microsoft. (It was then fixed in a hurry).
I have had other experiences at Microsoft suggesting that only when it becomes a PR problem for Microsoft will they fix something which does not fit their ideas of how the software is supposed to be used. Their answer in this case suggests that the feeling is that the solution is not to use untrusted sources of Access dbs. Just wait for someone in a business to show how this can be done using Access with far fewer permissions, and then it might get fixed.
Preview doesn't help when you are using it to invoke XSS vulnerabilities.
First of all, the links are not permanent and are more fragile because now you have 2 sources of failures rather than one (tinyurl could go down, as could the server you really want to reach). Hence it is certainly bad practice to use something like tinyurl for something which needs permanence and transparency.
However, I will agree that it is not going to damage the internet as we know it. If TinyURL becomes corrupt, shuts down, gets hacked, whatever, it is going to damage the users of the service and show them why this is a bad idea. However I don't see us becoming so dependant on these services that such damage can be said to cause serious problems for the internet as a whole.
BTW, one of the interesting uses I have for tinyurl is testing XSS vulnerabilities in web apps, especially when attacking limited-length fields. Oftne you can fit a script tag with a source attribte into a field using tinyurl that you can't using the full path. In addition to the legitimate testing angle, this also leads to issues of attackers using the service for the same purpose.
If you remember the pied piper story, it ended with the piper leading all the children of the town away to the mountain, where it closed after them. If it can be done with pests, are you saying we should think about the possibility it can be done with children too?
The idea is quite simple. They thought that Napster was a few bad apples stealing from them (please, don't attack me for saying this-- I am not agreeing with them, just saying what I think they believed). So they sued Napster, and similar services popped up.
The problem with organizational inertia is that it tends to build, and this was an unseen slippery slope. Pretty soon they found things had gone way out of control and pretty soon we see all out war with consumers (which has still not begun to abate despite these statements).
The war was inadvertently started when the Napster lawsuit was filed, in the same way that WWI was inadvertently started when Archduke Ferdinand embarked on his visit to Sarajevo.
You are aware that General Howe wrote in his diary about his sympathies for the colonists, right? Most of the other British Generals know, respected, and sympathized with the economic and political injustices in the colonies (Burgoyne was an exception and note that Howe withheld military support for Burgoyne against direct orders from the crown).
In the American revolution there were two sides: The British Crown, and almost everyone in the colonies (British military included). Believe it or not it was fought as a gentleman's war on both sides (Washington making arrangements with Howe to return captured Masonic regalia, for example).
The real cause of the American revolution was simple. British subjects in the American colonies were being denied basic political and economic rights which were afforded British subjects living in England. These included a right to trial by jury, a right to be represented in tax decisions, various economic controls, and the like. The Declaration of Independence documents these problems well (and seems particularly relevant today under the Administration of President George III). And the Bill of Rights, with a few exception, is based largely on the rights that British subjects in England were granted.
I would give up my right to vote for one election for enough money to make a strong and credible run as an independant candidate for the office of President. If it looked like I would lose anyway, I would back out and endorse the candidate I favored. This would make that money have a lot more impact than a single vote.
THe right to vote is not the same as the right to participate in the political system.
Then I would take the money and finance my own election :-)
How much is the right to vote worth vs. the right to participate in the political system? The latter is priceless. The former is negotiable.
And PC Nazis will complain about SS Drives because they associate them with the Schutzstaffel.