Just now when I tried to git push to drupal.org I got a long warning message that started with the following.
The RSA host key for git.drupal.org has changed, and the key for the corresponding IP address 140.211.10.43 is unknown.
The article Drupal.org Git Server Migration and its comments give a good explanation and discussion about how drupal.org has migrated to different servers as of early July.
The steps I took to fix the issue on my Linux Mint system were as follows, where the -R option for ssh-keygen means "remove the keys".
# ssh-keygen -R git.drupal.org
# ssh-keygen -R 140.211.10.43
# git fetch
The authenticity of host 'git.drupal.org (140.211.10.43)' can't be established.
RSA key fingerprint is 16:f5:44:6c:a1:c6:be:72:cd:98:b5:b7:7d:26:d6:14.
Are you sure you want to continue connecting (yes/no)? yes
After that, there were no further warnings in using git to access drupal.org.
Instead of git fetch probably any git command that accesses the remote repo would have the same effect, such as git pull or git clone.
Source:
Drupal.org Git Server Migration
https://www.drupal.org/node/2529356
Aug 7, 2015
Beta 10 --> Beta 11: String::checkPlain() moved to SafeMarkup::checkPlain()
It turns out that my blog post of last week was completely wrong in claiming that migrating the Optimizely module from Beta 10 to Beta 13 did not require any code changes. In fact, doing so completely breaks the site as soon as the module is enabled.
I'm not sure what went wrong during the migration. I must have had a brain burp and copied the wrong release into the test directory.
In any case, I have backtracked to Beta 11 and successfully migrated to it by making one coding change.
Method checkPlain() has been moved from class
Drupal\Component\Utility\String
to
Drupal\Component\Utility\SafeMarkup
I'm not sure what went wrong during the migration. I must have had a brain burp and copied the wrong release into the test directory.
In any case, I have backtracked to Beta 11 and successfully migrated to it by making one coding change.
Method checkPlain() has been moved from class
Drupal\Component\Utility\String
to
Drupal\Component\Utility\SafeMarkup
Jul 31, 2015
Beta 10 --> Beta 13: No code changes needed. But additional automated tests would help.
After a rather long digression of writing several posts about JavaScript in this blog, I got back to work on migrating the Optimizely module to Drupal 8, this time from Beta 10 to the recent Beta 13.
Once again, no code changes were needed.
Update: I made a serious mistake in migrating from Beta 10 to Beta 13. I thought that I had done so successfully without any code changes needed.
It turns out that I was testing against an older release, not Beta 13. In actuality, the Optimizely module completely breaks the site as soon as it is installed under Beta 13.
After discovering my mistake, I backtracked to Beta 11, where the method checkPlain() has been moved to a different class, that is, from String to SafeMarkup.
When I test this module against a new release of D8, I first carry out manual testing on the intended functionality, then run an automated suite of several tests written to the core Testing module.
When those automated tests all pass, they provide a lot of additional confidence that the module is working correctly.
At the moment, the suite consists only of the ones that I inherited when I started this conversion project. The suite lacks testing of two critical error conditions that must be detected when the user is editing projects.
Now, it's time for me to expand beyond that original set to provide some enhancements by adding new tests. For this module, D8 is a stable enough platform to start looking to new functionality.
Once again, no code changes were needed.
Update: I made a serious mistake in migrating from Beta 10 to Beta 13. I thought that I had done so successfully without any code changes needed.
It turns out that I was testing against an older release, not Beta 13. In actuality, the Optimizely module completely breaks the site as soon as it is installed under Beta 13.
After discovering my mistake, I backtracked to Beta 11, where the method checkPlain() has been moved to a different class, that is, from String to SafeMarkup.
When I test this module against a new release of D8, I first carry out manual testing on the intended functionality, then run an automated suite of several tests written to the core Testing module.
When those automated tests all pass, they provide a lot of additional confidence that the module is working correctly.
At the moment, the suite consists only of the ones that I inherited when I started this conversion project. The suite lacks testing of two critical error conditions that must be detected when the user is editing projects.
Now, it's time for me to expand beyond that original set to provide some enhancements by adding new tests. For this module, D8 is a stable enough platform to start looking to new functionality.
Jun 13, 2015
Notes on object-oriented JavaScript for o-o developers (part 5)
This post continues with more notes on distinctive features of object-oriented JavaScript as described in the book The Principles of Object-Oriented JavaScript.
This is a follow-up to the earlier Part 4 and is my final post related to that book.
** Private properties can be made by using closures.
In JavaScript, all properties of an object are publicly accessible. Unlike some other languages, there are no keyword access modifiers that correspond to public/protected/private.
However, you can get the same effect as private by defining an object in the context of a function that provides local variables and methods that you don't want to be public. The object is then used as a closure on those items that would otherwise not be accessible at all outside of the function.
So here's an example that I have copied from the above book, which nicely illustrates the idea.
var person = (function () {
var age = 25;
return {
name: "Nick",
getAge: function () { return age; },
growOlder: function () { ++age; }
}
})();
The outer, anonymously defined function is immediately invoked and returns an object which is assigned to the variable person.
The key concept here is that the two methods of that object refer to a local variable of the function. Because of those references, the lifetime of the local variable is extended, while at the same time it is not visible in any other code.
This use of closures is an example of the Module pattern in JavaScript.
This provides an individual object with a private property, but a similar technique can be used in a constructor so that every object created via the constructor gets its own private, instance property.
function Person (initial_age) {
var age = initial_age;
this.getAge = function () { return age; };
this.setAge = function (new_age) { age = new_age; };
this.growOlder = function () { ++age; };
}
nick = new Person(59);
lena = new Person(37);
console.log(nick.age); // undefined
Sources:
Closures
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures
Learning JavaScript Design Patterns
http://www.addyosmani.com/resources/essentialjsdesignpatterns/book/
This is a follow-up to the earlier Part 4 and is my final post related to that book.
** Private properties can be made by using closures.
In JavaScript, all properties of an object are publicly accessible. Unlike some other languages, there are no keyword access modifiers that correspond to public/protected/private.
However, you can get the same effect as private by defining an object in the context of a function that provides local variables and methods that you don't want to be public. The object is then used as a closure on those items that would otherwise not be accessible at all outside of the function.
So here's an example that I have copied from the above book, which nicely illustrates the idea.
var person = (function () {
var age = 25;
return {
name: "Nick",
getAge: function () { return age; },
growOlder: function () { ++age; }
}
})();
The outer, anonymously defined function is immediately invoked and returns an object which is assigned to the variable person.
The key concept here is that the two methods of that object refer to a local variable of the function. Because of those references, the lifetime of the local variable is extended, while at the same time it is not visible in any other code.
This use of closures is an example of the Module pattern in JavaScript.
This provides an individual object with a private property, but a similar technique can be used in a constructor so that every object created via the constructor gets its own private, instance property.
function Person (initial_age) {
var age = initial_age;
this.getAge = function () { return age; };
this.setAge = function (new_age) { age = new_age; };
this.growOlder = function () { ++age; };
}
nick = new Person(59);
lena = new Person(37);
console.log(nick.age); // undefined
Sources:
Closures
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures
Learning JavaScript Design Patterns
http://www.addyosmani.com/resources/essentialjsdesignpatterns/book/
Jun 1, 2015
Syntax explanation of (function ($) { ..... })(jQuery)
A few months ago when I had to modify some JavaScript, I ran across code like the following that just baffled me in terms of the basic
syntax.
(function($){
$(document).ready( ..... );
})(jQuery);
I'm now in a much better position to explain at the language level what's going on.
This explanation is not about jQuery nor about jQuery plugins, which a web search will show results for, such as the second article mentioned below.
Previously, I wrote that one of the ways to code the literal definition of a function is by using an expression that starts with the keyword function but does not include a name.
For example, this code defines an anonymous function and assigns it to a variable.
var helloWorld = function() {
console.log("hello, world");
}
The right-hand side of the = operator must be an expression that provides a value. In this case, it's a function object.
Likewise, here's a definition of another function object. The parentheses around it force it to be treated as an expression rather than as a regular function declaration.
(function ($) {
$(document).ready( ..... );
})
A single dollar sign $ is a valid identifier. So in this case, that's the name of the function's argument. That argument is apparently expected to be a function since $(document) looks like a call of $, whatever the actual argument is.
Let's add the final piece.
(function ($) {
$(document).ready( ..... );
})(jQuery);
The (jQuery) part of this expression means call the anonymously defined function, with jQuery as the actual argument.
In general, this kind of construct is known as an Immediately Invoked Function Expression (IIFE).
There's a slightly different way to write this code. I prefer the above, and it's what I've been seeing in practice. But the following is also correct.
(function ($) {
$(document).ready( ..... );
}(jQuery));
Sources:
Immediately-Invoked Function Expression (IIFE)
http://benalman.com/news/2010/11/immediately-invoked-function-expression/
What does (function($) {})(jQuery); mean?
http://stackoverflow.com/questions/2937227/what-does-function-jquery-mean
(function($){
$(document).ready( ..... );
})(jQuery);
I'm now in a much better position to explain at the language level what's going on.
This explanation is not about jQuery nor about jQuery plugins, which a web search will show results for, such as the second article mentioned below.
Previously, I wrote that one of the ways to code the literal definition of a function is by using an expression that starts with the keyword function but does not include a name.
For example, this code defines an anonymous function and assigns it to a variable.
var helloWorld = function() {
console.log("hello, world");
}
The right-hand side of the = operator must be an expression that provides a value. In this case, it's a function object.
Likewise, here's a definition of another function object. The parentheses around it force it to be treated as an expression rather than as a regular function declaration.
(function ($) {
$(document).ready( ..... );
})
A single dollar sign $ is a valid identifier. So in this case, that's the name of the function's argument. That argument is apparently expected to be a function since $(document) looks like a call of $, whatever the actual argument is.
Let's add the final piece.
(function ($) {
$(document).ready( ..... );
})(jQuery);
The (jQuery) part of this expression means call the anonymously defined function, with jQuery as the actual argument.
In general, this kind of construct is known as an Immediately Invoked Function Expression (IIFE).
There's a slightly different way to write this code. I prefer the above, and it's what I've been seeing in practice. But the following is also correct.
(function ($) {
$(document).ready( ..... );
}(jQuery));
Sources:
Immediately-Invoked Function Expression (IIFE)
http://benalman.com/news/2010/11/immediately-invoked-function-expression/
What does (function($) {})(jQuery); mean?
http://stackoverflow.com/questions/2937227/what-does-function-jquery-mean
Subscribe to:
Posts (Atom)