I was reading an interview with Peter Dale Scott about America's "Deep State", on the Global Research website. I was, previously, blissfully unaware of either. As often happens, I began to wonder: who are these people and should I believe them?
A quick review of the About page provided lots of information, but not much about who controls the site content or what motivates them. There is so much propaganda and disinformation on the Internet, that I tend to be skeptical.
This got me thinking about who to trust and I thought of one of the sources I find credible on political issues: Noam Chomsky. Despite him being too busy and me being nobody, I wrote him an email, to ask his advice about who and what to trust.
Then I went back to review the articles on Noam's website, to see what I could find along the lines of advice on the matter. Thus I ended up reading "The Responsibility of Intellectuals", the first footnote of which referenced a "Citizens'" White Paper - The Politics of Escalation in Vietnam, one of the authors of which was Peter Dale Scott.
So, does this make the Global Research website and Peter Dale Scott more trustworthy? Certainly, for me, in the case of Peter Dale Scott and somewhat for the website, on the assumption that what I was reading was an accurate representation of an interview with Mr. Scott.
How can one validate a source other than by knowing what they tell you by other means that confirm the truth of what they say? But then, one already knows what they say: it is nothing new. Otherwise, it is by reputation, past experience and blind faith. The concepts of a web of trust seem relevant. But so many people are deluded by propaganda or ignorance, even common beliefs are not trustworthy.
Who to trust? It is a hard problem.
Saturday, June 21, 2014
Sunday, December 15, 2013
Building PouchDB on Windows 7
Building PouchDB on Windows 7 has been a rather miserable experience. Not because of PouchDB but because of the Microsoft Windows development tools: Visual Studio and Windows SKD.
For hours, every attempt to 'npm install' the PouchDB package failed with:
Finally, I stumbled on https://github.com/node-xmpp/node-expat/issues/57 - an issue for node-expat. The last post there was from kosmobot:
Much thanks to kosmobot!!
For hours, every attempt to 'npm install' the PouchDB package failed with:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(29The Internet is full of reports of this warning and this error. Most of them with only cryptic hints as to how to resolve them or nothing more than the comment "works for me". I spent over four hours installing, uninstalling, re-installing various packages from Microsoft and rebooting a mind-boggling number of times, following advice here and there. None of it made any difference. Always, the same warning and error.
7,5): warning MSB8003: Could not find WindowsSDKDir variable from the registry.
TargetFrameworkVersion or PlatformToolset may be set to an invalid version nu
mber. [C:\Users\ian\Documents\Entrain\pouchdb\pouchdb-master\node_modules\level
\node_modules\leveldown\deps\leveldb\leveldb.vcxproj]
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\Microsoft.Cpp.x
64.targets(146,5): error MSB6006: "CL.exe" exited with code -1073741515. [C:\Us
ers\ian\Documents\Entrain\pouchdb\pouchdb-master\node_modules\level\node_module
s\leveldown\deps\leveldb\leveldb.vcxproj]
Finally, I stumbled on https://github.com/node-xmpp/node-expat/issues/57 - an issue for node-expat. The last post there was from kosmobot:
This actually solved the problem. So, I had all the prerequisites installed all along - the only problem was setting up the environment. Too bad none of Microsoft's replies to reports of the warning or error bother to mention this. If only I had found this post earlier, I might have done some useful work this morning.
Much thanks to kosmobot!!
Monday, November 18, 2013
Wednesday, June 26, 2013
Making Enemies
If you treat people as enemies rather than as people, declaring them to be enemies, to be evil and not worthy of the rights of people, if you declare and wage war against them and use aggressive violence against them and oppress them and give them no choice but to be enemies, then you make them into enemies, whether they were enemies or not.
While, through war and violence, you may gain short term tactical advantages, the enemies you make will, in the longer term, be a heavy burden.
On the other hand, if you treat people as people, respect and defend their rights, defend their dignity, help them in their struggles for health and happiness and ensure that not only is justice done but that justice is seen to be done, then those good people who are your friends will be your friends and support you and some of those who are your enemies might change their attitude towards you.
There will still be some evil in everyone. It is part of human nature. It predominates in some. Treat even these people fairly and ensure that not only is justice done but that justice is seen to be done. To do otherwise promotes and perpetuates and exacerbates the evil.
There will still be people who make themselves your enemies, despite your best efforts not to deserve being treated as such. But the burden will be less, in the long run than if you, every day, make more enemies by your own initiative.
Be what you wish everyone else was.
While, through war and violence, you may gain short term tactical advantages, the enemies you make will, in the longer term, be a heavy burden.
On the other hand, if you treat people as people, respect and defend their rights, defend their dignity, help them in their struggles for health and happiness and ensure that not only is justice done but that justice is seen to be done, then those good people who are your friends will be your friends and support you and some of those who are your enemies might change their attitude towards you.
There will still be some evil in everyone. It is part of human nature. It predominates in some. Treat even these people fairly and ensure that not only is justice done but that justice is seen to be done. To do otherwise promotes and perpetuates and exacerbates the evil.
There will still be people who make themselves your enemies, despite your best efforts not to deserve being treated as such. But the burden will be less, in the long run than if you, every day, make more enemies by your own initiative.
Be what you wish everyone else was.
Friday, May 24, 2013
Eating hamburgers is not an act of vegetarian extremism
I have read some reports that globally, in the long term, death from violence of all kinds is decreasing - an ever smaller percentage of people die from violence. Yet once free, liberal democracies are revolutionizing themselves in order to better pursue wars on drugs and terrorism and anything else they don't like, but terrorism is a hot topic lately and the war on terror seems to be causing all sorts of bother and expense, diminishing the lives of the many.
The war on terror seems to thrive on extreme rhetoric and the rhetoric of extremism, bigotry and hatred. Those in power seem little inclined to moderation, diplomacy, reconciliation or support and engagement to overcome problems.
Anyway, with all the talk of extremism and terrorism, I really got a good laugh from Nabil Goes In. The world needs more people with such passionate, compassionate moderation and sensibility.
The war on terror seems to thrive on extreme rhetoric and the rhetoric of extremism, bigotry and hatred. Those in power seem little inclined to moderation, diplomacy, reconciliation or support and engagement to overcome problems.
Anyway, with all the talk of extremism and terrorism, I really got a good laugh from Nabil Goes In. The world needs more people with such passionate, compassionate moderation and sensibility.
Saturday, April 27, 2013
Magento object initialization (_construct Vs __construct)
Some classes in Magento define function _construct, some define __construct, some define both and some define neither. What's going on?
The function __construct is executed by PHP when an object is instantiated, if it exists, but function _construct is not. To PHP there is nothing special about _construct.
Initialization in Magento seems to be quite variable. Many classes define __construct. Many, but not all of these, execute parent::__construct - some before and some after local initialization.
In a few cases, __construct ends with $self->_construct(). The Varien_Object class is an example. In these cases, sub-classes can define _construct, in which case the parent's __construct will run and the sub-class's _construct will be run.
Class Varien_Object defines function _construct with the following comment:
Only a few of the sub-classes of Varien_Object define function _construct. I haven't reviewed them exhaustively, but a significant majority of those I reviewed did not define function _construct.
Class Mage_Core_Block_Abstract also defines function __construct to execute $self->_construct(), and defines function _construct with the comment:
On the other hand, at least one sub-class of Varien_Object (Mage_Core_Model_Email) defines function __construct and does not execute parent::__construct(). Nor does function __construct in class Mage_Core_Model_Email do the equivalent of function __construct in class Varien_Object. So, the function __construct in class Varien_Object is not always executed in sub-classes of Varien_Object.
Sub-classes defining __construct and executing parent::__construct() seems to be the most common. It is hard to imagine any advantage of using function _construct(), as with Varien_Object. It has been suggested that it makes it less likely to forget to execute parent::__construct(), but this hardly seems likely. One would have to remember to define function _construct rather than function __construct. If one can remember this, then surely one can remember to execute parent::__construct(). It would be a more credible explanation if the use of function _construct were common: it might become habitual or one were not otherwise familiar with PHP. But in fact, classes using function _construct are uncommon. The vast majority of __construct functions do not execute $self->_construct().
Keep in mind that if a sub-class of a class that defines function __construct to execute $self->_construct() defines function _construct and a sub-class of that sub-class also defines function _construct, then when the root class executes $self->_construct, only that in the sub-sub-class will be executed: the function _construct of the intermediate class will not be executed, unless the sub-sub-class executes parent::_construct().
I haven't reviewed the classes of Magento exhaustively, but I have reviewed a significant number and thus far have seen only one (Mage_Core_Block_Template) where function _construct executes parent::_construct().
If sub-sub-classes are going to execute parent::_construct(), it seems to me that it would be simpler to simply use __construct and parent::construct() in the way that would be obvious to any PHP programmer, and do away with function _construct. But that's just my opinion.
In summary, in a few classes function __construct executes $self->_construct() and some sub-classes of these classes define function _construct rather than function __construct. I know neither the motivation nor the benefit of this, particularly as it is so uncommon. It is certainly not the norm in Magento. There has been some discussion on the Magento forums, but no explanation from a core team developer that I have seen.
The function __construct is executed by PHP when an object is instantiated, if it exists, but function _construct is not. To PHP there is nothing special about _construct.
Initialization in Magento seems to be quite variable. Many classes define __construct. Many, but not all of these, execute parent::__construct - some before and some after local initialization.
In a few cases, __construct ends with $self->_construct(). The Varien_Object class is an example. In these cases, sub-classes can define _construct, in which case the parent's __construct will run and the sub-class's _construct will be run.
Class Varien_Object defines function _construct with the following comment:
/**
* Internal constructor not depended on params. Can be used for object initialization
*/
Only a few of the sub-classes of Varien_Object define function _construct. I haven't reviewed them exhaustively, but a significant majority of those I reviewed did not define function _construct.
Class Mage_Core_Block_Abstract also defines function __construct to execute $self->_construct(), and defines function _construct with the comment:
/**At least in this case there is a clear preference stated regarding __construct, but still not rationale.
* Internal constructor, that is called from real constructor
*
* Please override this one instead of overriding real __construct constructor
*
*/
On the other hand, at least one sub-class of Varien_Object (Mage_Core_Model_Email) defines function __construct and does not execute parent::__construct(). Nor does function __construct in class Mage_Core_Model_Email do the equivalent of function __construct in class Varien_Object. So, the function __construct in class Varien_Object is not always executed in sub-classes of Varien_Object.
Sub-classes defining __construct and executing parent::__construct() seems to be the most common. It is hard to imagine any advantage of using function _construct(), as with Varien_Object. It has been suggested that it makes it less likely to forget to execute parent::__construct(), but this hardly seems likely. One would have to remember to define function _construct rather than function __construct. If one can remember this, then surely one can remember to execute parent::__construct(). It would be a more credible explanation if the use of function _construct were common: it might become habitual or one were not otherwise familiar with PHP. But in fact, classes using function _construct are uncommon. The vast majority of __construct functions do not execute $self->_construct().
Keep in mind that if a sub-class of a class that defines function __construct to execute $self->_construct() defines function _construct and a sub-class of that sub-class also defines function _construct, then when the root class executes $self->_construct, only that in the sub-sub-class will be executed: the function _construct of the intermediate class will not be executed, unless the sub-sub-class executes parent::_construct().
I haven't reviewed the classes of Magento exhaustively, but I have reviewed a significant number and thus far have seen only one (Mage_Core_Block_Template) where function _construct executes parent::_construct().
If sub-sub-classes are going to execute parent::_construct(), it seems to me that it would be simpler to simply use __construct and parent::construct() in the way that would be obvious to any PHP programmer, and do away with function _construct. But that's just my opinion.
In summary, in a few classes function __construct executes $self->_construct() and some sub-classes of these classes define function _construct rather than function __construct. I know neither the motivation nor the benefit of this, particularly as it is so uncommon. It is certainly not the norm in Magento. There has been some discussion on the Magento forums, but no explanation from a core team developer that I have seen.
Magento observer class
One of the parameters of a Magento observer is the 'class'.
For example, the Magento wiki has an example of customizing Magento using an observer. This example includes configuration of the module that provides the observer:
I wondered why, in all the examples I found, the observer class was always a 'Model' class. It seems strange to me that a 'Model' (think MVC) would handle an event. I think of a Model as getting or persisting data. A controller seems a more appropriate component for handling an event. But, again, every example I have seen executes a method from a Model class. So, I had a look at the Magento code to see what was going on and whether there were any clues as to why a Model rather than a Controller.
In some cases, like the example above, the class name is given explicitly. In every case I have seen, the class name includes 'Model'. Note that in a case like this example, the Mage __autoload function changes '_' to directory separator so, on a Linux system, that class would be loaded from Xyz/Catalog/Model/Price/Observer.php. In this case, it is just a class and needn't be a Model as far as I can tell.
In other cases, the class is specified differently: as 'module/model'. In this case, the processing within Magento inserts 'Model' into the class name, so it is a bit more explicitly a Model class. See getGroupedClassName in Mage_Core_Model_Config for the full details. getGroupedClassName is called to transform the class name if it contains '/', in which case the class becomes getGroupedClassName('model', $class).
For example, the Magento wiki has an example of customizing Magento using an observer. This example includes configuration of the module that provides the observer:
<?xml version="1.0"?>
<config>
<global>
<models>
<xyzcatalog>
<class>Xyz_Catalog_Model</class>
</xyzcatalog>
</models>
<events>
<catalog_product_get_final_price>
<observers>
<xyz_catalog_price_observer>
<type>singleton</type>
<class>Xyz_Catalog_Model_Price_Observer</class>
<method>apply_discount_percent</method>
</xyz_catalog_price_observer>
</observers>
</catalog_product_get_final_price>
</events>
</global>
</config>
I wondered why, in all the examples I found, the observer class was always a 'Model' class. It seems strange to me that a 'Model' (think MVC) would handle an event. I think of a Model as getting or persisting data. A controller seems a more appropriate component for handling an event. But, again, every example I have seen executes a method from a Model class. So, I had a look at the Magento code to see what was going on and whether there were any clues as to why a Model rather than a Controller.
In some cases, like the example above, the class name is given explicitly. In every case I have seen, the class name includes 'Model'. Note that in a case like this example, the Mage __autoload function changes '_' to directory separator so, on a Linux system, that class would be loaded from Xyz/Catalog/Model/Price/Observer.php. In this case, it is just a class and needn't be a Model as far as I can tell.
In other cases, the class is specified differently: as 'module/model'. In this case, the processing within Magento inserts 'Model' into the class name, so it is a bit more explicitly a Model class. See getGroupedClassName in Mage_Core_Model_Config for the full details. getGroupedClassName is called to transform the class name if it contains '/', in which case the class becomes getGroupedClassName('model', $class).
Subscribe to:
Posts (Atom)
call "C:\Program Files\Microsoft SDKs\Windows\v7.1\bin\Setenv.cmd" /Release /x86call "C:\Program Files\Microsoft SDKs\Windows\v7.1\bin\Setenv.cmd" /Release /x64