http://www.google.com/ipv6/statistics.htmlDo I hear 2%? (Probably not for a little while.) Yes I know it is sad to be interested in this graph but hey, one has to be into something.
Monday, 18 February 2013
IPv6 exceeds 1% of google search traffic (continuously)
In the ongoing march towards an IPv6 only Internet, IPv6 is not a speedy traveller but it did reach a mini-milestone this week. Google reported that IPv6 traffic was greater than 1% of it's total traffic all week, on a regular ordinary week (well the week has the same basic shape as most non-holiday weeks). Usage continues to edge higher and higher:
Tuesday, 12 February 2013
GPG key managment
As all good boys did, I (relatively) recently generated a nice shiny new GPG key, all 4096 bits of it. I have switched everything over to this key and have been happy. Today I was wondering whatever happened to the old key. After some minutes trying to remember what the passphrase (oops) I finally managed to find and open the key.
Time it seems to revoke it so that I never have to worry about it again (and before I forget the passphrase for good). Revoking a key essentially puts an end date on the key, it says any use of the key after this date is definitively invalid. Luckily revoking a key (that you can remember the passphrase for) is relatively simple:
At least now the keys I care about are protected and those I do not are put out of use.
Time it seems to revoke it so that I never have to worry about it again (and before I forget the passphrase for good). Revoking a key essentially puts an end date on the key, it says any use of the key after this date is definitively invalid. Luckily revoking a key (that you can remember the passphrase for) is relatively simple:
gpg --edit keyWhile I was at it I started to wonder about losing keys and how one guards against total loss of a key. The received wisdom is to set an expiration date on your key. These may be extended at any time, even after the key has technically expired, assuming you still have the private key. If you do not then at least the key will automatically fall out of use when it expires. Adding an expiry date to a key is also pretty simple:
gpg> revoke
gpg> save
gpg --send-key
gpg --edit-keyNote here I am setting the subkey (or keys, key 1 and higher) to expire in a year, and the main key to expire in 18 months.
gpg> key 0
gpg> expire
...
Key is valid for? (0) 18m
gpg> key 1
gpg> expire
Changing expiration time for a subkey.
...
Key is valid for? (0) 12m
gpg> save
gpg --send-key
At least now the keys I care about are protected and those I do not are put out of use.
Monday, 11 February 2013
HTML should be simple even with a javascript infection
Having been there in the simple days when a web server was a couple of hundred lines of code, and when HTML was a simple markup language pretty much only giving you hyperlinks and a bit of bold, I have always found javascript at best an abomination and certainly to be avoided in any personal project.
My hatred mostly stems from just how unclean the page source became when using lots of fancy javascript and how javascript dependant everything became as a result. Turning javascript off just broke everything, basically meaning you had to have it enabled or not use the sites. This is just wrong.
Recently I have been helping a friend to build their own website, a website which for reasons I find hard to understand could not be simple, with just links and bold, but really had to have popups, fading things, slides which move, all those things you really can only do easily and well in javascript. Fooey.
Reluctantly embracing these goals I spent some time implementing various bits of javascript and ended up as predicted in some kind of maze of twisty passages all the same. I was fulfilling my own nightmare. Then something happened. I accidentally discovered jquery. Now jquery is no panacea at all, yes it does simplify the javascript you need to write so it is clearer and cleaner which is no bad thing. The real jolt was the methodology espoused by the community there. To write pages which work reasonably well with just HTML and CSS, and then during page load if and only if javascript is enabled rewrite the pages to add the necessary magic runes. Now you can have nice maintainable HTML source files and still have fancy effects when available.
I have used this to great effect to do "twistable" sections. When there is no javascript you get a plain document with all of the text displayed at page open. If it is available then little buttons are injected into the sections to allow sections to be opened and closed on demand and the body is hidden by default. All without any significant markup in the main HTML source, what little semantic markup there is has no effect:
My hatred mostly stems from just how unclean the page source became when using lots of fancy javascript and how javascript dependant everything became as a result. Turning javascript off just broke everything, basically meaning you had to have it enabled or not use the sites. This is just wrong.
Recently I have been helping a friend to build their own website, a website which for reasons I find hard to understand could not be simple, with just links and bold, but really had to have popups, fading things, slides which move, all those things you really can only do easily and well in javascript. Fooey.
Reluctantly embracing these goals I spent some time implementing various bits of javascript and ended up as predicted in some kind of maze of twisty passages all the same. I was fulfilling my own nightmare. Then something happened. I accidentally discovered jquery. Now jquery is no panacea at all, yes it does simplify the javascript you need to write so it is clearer and cleaner which is no bad thing. The real jolt was the methodology espoused by the community there. To write pages which work reasonably well with just HTML and CSS, and then during page load if and only if javascript is enabled rewrite the pages to add the necessary magic runes. Now you can have nice maintainable HTML source files and still have fancy effects when available.
I have used this to great effect to do "twistable" sections. When there is no javascript you get a plain document with all of the text displayed at page open. If it is available then little buttons are injected into the sections to allow sections to be opened and closed on demand and the body is hidden by default. All without any significant markup in the main HTML source, what little semantic markup there is has no effect:
<h2 class="twist-title">Section Title</h2>
<div class="twist-body">
Section Text
</div>
Now that is source you can be proud of. Yes there is some site-wide jquery instantiations required here which I will avoid including in its full glory as it is rather messy. But this example shows the concept:
$(function() {
$(".twist-title").prepend("<span class=\"twist-plus\">+</span>
<span class=\"twist-minus\">-</span> ")
$(".twist-body").hide();
$(".twist-title").click(function (event) {
$(this).children('.twist-plus').toggle();
$(this).children('.twist-minus').toggle();
$(this).next().toggle();
})
$(".twist-title").css("cursor", "pointer");
});
Ok this is not so easy to understand, but the majority of the code, the HTML pages that the people who write the content have to look at is easy to understand. I think you only agree this is a win all round.
Subscribe to:
Posts (Atom)