ref=2:me=umh:b-adapt=2:weightb=0:vbv-maxrate=9500:vbv-bufsize=9500:subme=9:trellis=2:psy-rd=1|0.1

I use a CRF20.

handbrake x264 settings for DVD rip

[Edit]: A very helpful source about x/h264 options: https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping

Just drag & drop the following link to you bookmark address: Inject jQuery.

NB: jQuery is then inserted without using the compatibility mode (typing “jQuery” instead of “$” is too much a hassle for me).

Once jQuery is loaded, you can then play around in the console. You can do a lot things. For instance on google news,

$('.esc-layout-article-cell h2 a span').each(function(){ console.log($(this).text()); });

will scrape the news titles on the page.

I followed the instructions given on the page above but it just did not work. The issue there is that the 64bits version of the 2.3 CAPT drivers do not work on Ubuntu 11.10.

After struggling several hours trying to build the proper symlinks for the driver and figuring out why AppArmor was blocking cups, I ended up with a much simpler solution.
The solution for me was to use the 2.2 version of Michael Grutz’s repository.

sudo add-apt-repository ppa:michael-gruz/canon

The repository does not include an oneiric version. You will need to update your /etc/apt/sources.list.d/michael-gruz-canon.list file and replace oneiric with natty.

Then :
1- Install the driver

$ sudo apt-get update
$ sudo apt-get install cndrvcups-common cndrvcups-capt

2 – Restart Cups

$ sudo service cups restart

3 – Add your printer to Cups

$ sudo /usr/sbin/lpadmin -p PRINTERNAME -m CNCUPSLBP7200CCAPTK.ppd -v ccpd://localhost:59787 -E

The ppd given here is for the LBP7200Cdn. If you have another printer, select the appropriate driver for it (refer to the Ubuntu page above or have a look at your /usr/share/cups/model folder).

4 – Link your cups printer to the canon ccp daemon

$ sudo ccpdadmin -p PRINTERNAME -o net:THE_PRINTER_IP

This command is for a network printer. If you are installing an USB printer, replace the net:IP part by your usb device : /dev/lp0

5 – Start the canon printing daemon

$ sudo /etc/init.d/ccpd start

Check that the daemon is properly started:

$ sudo /etc/init.d/ccpd status

You should get something like

/usr/sbin/ccpd: 15263 15258

With two process ids running.

You should now be able to print. If everything went fine, you can now add the canon daemon to your startup.

$ sudo update-rc.d ccpd defaults 90

PS : My ubuntu systems are now able to print but I still cannot make it work on my beloved CrunchBang distro.
If anyone made it work on Debian, I am looking for the installation process.

Add

deb http://ppa.launchpad.net/hotot-team/ppa/ubuntu maverick main

to your /etc/apt/sources.list

Then

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys A29228DD41011AE2
$ sudo apt-get update
$ sudo apt-get install hotot

As I was latetly assigned to a new project at my new job, the question of the choice of the javascript framework to use raised. My fellow co-workers were used to Mootools and our talented HTML integrator had already used some Mootools code in here work.

So Mootools would it be.

jQuery was the only javascript I had really worked with and I took this as a great opportunity to learn something new. So I went for it quite enthusiastically.

After a few weeks have passed by, I start to get my own opinion on the relative lacks and strengths of both frameworks. Note that I am still a new user of Mootols and my opinion will probably evolve.

As I am a little lazy, this post will be organised as a comment of the one from Aaron Newton of Clientcide, which he posted on http://jqueryvsmootools.com/

As you might have already gotten it from the title, my opinion is not exactly always matching his’.

2 good frameworks

jQuery and Mootools are 2 good frameworks. When playing the “who is using what” game, jQuery presents a very impressive reference list. But if Mootools’list is shorter, it can be proud of containing some prestigious names that suffice to prove its quality (w3c, vimeo, netvibes etc.)

I obviously agree with Aaron Newton on this point: none of these two frameworks is a bad choice.

The mottos say it all

Indeed, mottos say long.

[..]f you go to the jQuery site, here’s what it says at the top of the page:

jQuery is a fast and concise JavaScript Library that simplifies HTML document traversing, event handling, animating, and Ajax interactions for rapid web development. jQuery is designed to change the way that you write JavaScript.

..and if you go to MooTools, this is what you’ll find:

MooTools is a compact, modular, Object-Oriented JavaScript framework designed for the intermediate to advanced JavaScript developer. It allows you to write powerful, flexible, and cross-browser code with its elegant, well documented, and coherent API. [..]

Am I the only one to find that one of the two mottos is a little more arrogant than the other? Seriously?…

« .. designe for the intermediate to advanced Javascript developer.».. .

The important fact here is not about the truth of the statement (personally, I consider Mootools as being very usable by a beginer). The important fact about this statement is that the Mootools team addresses people who consider themselves as confirmed developers.

Aaron even goes further this way by, if I sum it up, considering that “If you are interested in JavaScript and what makes it interesting, powerful, and expressive, then, […] MooTools is the better choice.

I strongly disagree with this last point. Actually, I even think that liking Javascript is a reason not to use Mootools. But more about this later.

The Learning Curve and The Community

Indeed, the jQuery community is much broader than Mootools’ one. The author is skipping an important point here: The bigger your community is, the more you get reported bugs, the more developers you have to work on them and to improve th code base, the more contributors you get to develop and share plugins.
When talking about stability, frequency and importance of release, there again, jQuery is an enormous step ahead.

As an example: Maybe I am not lucky but a just a couple of days after I started using Mootools, I encountered a annoying bug. In Mootools More 1.3.1.1, the Form validation does not work on select elements.
Just try to implement a callback for elementFail and you won’t get ever anything in your element variable.

The bug is referenced and corrected on Github for a while:
https://github.com/mootools/mootools-more/commit/358378c5b. But it is still not fixed yet in the official download version.

What Javascript is Good For

The author here briefly describes the prototypal approach of the object model used by Javascript. His conclusion is that “the bad news is that vanilla JavaScript doesn’t make these powerful things very useful or accessible”.

Huuh? oO? What?

OK, I agree that the prototypal model is (too) often unknown of developers. The excellent article from Steve Yegge on the subject and “Javascript, the good parts” from the also excellent Douglas Crockford, will help the curious ones to get an insight on the subject and about how Javascript implements it.

But how can one say that the language is responsible for making these powerful things useless or inaccessible?
Here how you declare an object in javascript:

var my_object = {
	property: ‘a property’,
	method: function(){
		alert(‘Hello World’);
	}
};

And here is how to inherit from this object:

var tmp = function(){ };
tmp.prototype = my_object;
var my_herited_object = new tmp();

OK, maybe I am not totally sincere. The last bit of code may not be that obvious to everybody. But still, where does Javascript make it useless or inacessible?

Mootools makes Javascript itself more fun

Aaron Newton explains here that Mootools is trying to make Javascript better, to make it “the way it should be”.

So, Mootools extends the prototypes of the native types to bring them missing functionalities.

Let’s just remember here that the augmentation provided to Element are mainly focused on the DOM manipulation, a domain where jQuery is excellent.
The other “ameliorations” given to the native types, like Array or String are sure welcome, but they are not a Mootools exclusivity.
jQuery also includes some helper functions, without integrating them to the native prototypes.

Finally, Mootools proposes its famous Class concept.
The author pretends here that Mootools is not trying to introduce a class-based object model in javascript but that its purpose is instead to simplify the use of the prototypal model.

Sure… And I am the Queen of England…

Simple question then: Why call an object/namespace that is dedicated to simplify the use of the prototypal model with the name of its concurrent model?
In practice, the use of Mootools Class is clearly a mimic of a “classical” class object model.

Assuming that the will of Mootools was really to facilitate the use of the prototypal system, the term “Class” can only lead to confusion for the developer.

I like Javascript for, among other things, its prototypal approach. And because I like Javascript, I do not need Mootools Class system.

jQuery does not provide any “inheritance model” for one good reason: it is already built in Javascript and works perfectly well.
The additional layer provided by Mootools is confusing and unnatural to me, and should, I believe, be to any javascript developer.

jQuery makes the DOM more fun

Another sophism from the author. jQuery would only be a “toolbox” dedicated to the manipulation of the DOM only, where Mootols would a real, much more abstract and noble “framework”.

The fact is it is false.

The main thing is that jQuery is focused on utile things. Even if, notably thanks to node.js, we start seeing some javascript running out of the browser, the truth is the huge majority of the existing javascript worldwide is interpreted by the browsers.
And the manipulation of the DOM is, indeed, a very important point for the developer.

But reducing jQuery to the DOM handling is fallacious. The Ajax layer, the utility functions we already talked about or the processing of events by groups introduced in 1.5 do not have any direct relation with the DOM.

Anything You Can Do I Can Do Better

Let’s skip this chapter where the author is trying to convince us without any evidence that the scope of Mootools is wider than jQuery’s one.
I already explained how useless the so-said extra area covered by Mootools was to me.

Mootools Lets You Have It Your Way

Let’s skip it too.

I just do not understand one willing to mimic Mootools.

When manipulating the DOM, Mootools is incoherent and verbose.
On all the Class stuff, everything can be done simpler and cleaner in vanilla Javascript.

Chaining as a Design Pattern

Where we are explained that we can access the properties of an object that is sent as a result of a function.
Thank, we knew it already.

Reusing Code with JQuery

Here again, we are told that using jQuery, we can only manipulate the DOM.
I am sorry Aaron but far before knowing Mootools, I was creating, using and _even_ using some inheritance principles in Javascript.

A little word on “There’s not a lot of complexity here, which makes it easy for anyone to write jQuery plug-ins – they’re just single functions.”
Let’s just remember that, contrary to a language like PHP, in Javascript, a function is an Object, that we can freely define and use complete objects in it, or other embed functions.
Because functions are closures, they can also access everything outside themselves that were accessible from their definition scope.
There is actually no limit to how complex a function can be.
Actually, the whole jQuery framework (I use this word on purpose) is one single function.

The point about jQuery-UI also looks out-of-subject to me. The way jQuery-UI is included in jQuery is not dictated by jQuery. It is just a choice from the jQuery UI team. Let’s just remember one simple statement that one may have forgotten:
This is all javascript. The source is right there. We can code around the way we want.

Reusing Code with Mootools

First a word about the extension of the native prototypes.
Personally, I am balanced on this question.

Of course, I find (too) dangerous to modify or extend the behaviour of objects that are share across the whole execution context and then, most probably, by other scripts and libraries (including Google Analytics or Maps).
On the other hand, I can understand how tempting it can be to have a trim method right from any String.

Using an inherited prototype is not a solution as this would obviously imply lots of tedious casts.

The alternative, and my personal choice, it to externalise these functions, like jQuery does with c jQuery.trim() for instance.
Of course, we loose in syntaxic quality by writing jQuery.trim( my_string ) rather than my_string.trim() but at least, we are sure that we do not interfere with an insane external programmer who decided to use String.trim as a way to give the current date.

About the use of CSS selectors

One question: What’s the use of the $ function in Mootools?

It is just an alias for document.getElementById, does not provide any additional value and introduces some confusion with $$.

Let’s just remember that $$(‘#myid’)[0] will give the same result as $(‘myid’).
So, the purpose of $ would be to save 4 chars?

I am starting to assume that the $ function’s real purpose is to conflict with other frameworks like jQuery or Prototype.

About the Namespaces

Let’s finish with a point that I have not talked about yet and that I suspect Aaron Newton to avoid.
This point is one of the big ones that make me think Mootools won’t ever be my favourite framework.
I am of course talking about the use of namespaces.

While we can see jQuery’s constant effort to limit its impact on the window namespace to the two $ and jQuery variables, we cannot say the same thing about Mootools.

Mootools is not very shy when talking about exposing its insides to the global world.

We of course get $ and $$ but also a lot of other ones: Element, Class, Slick. If you use Mootools More, some more objects wil also be set globally: Form, FX etc.

Seriously, what is the risk another script uses a variable named Form?
Quite high if you ask me.

For a framework “designed for the intermediate to advanced JavaScript developer”, I find this is quite a big noob mistake.

Conclusion

As you may have understood, I am not a Mootools fanboy. jQuery of course does not need me to still be the dominant framework for a while.

Let’s just remember somethins that may have been forgottent during the reading of this post: Mootools is not a bad framework.
The only fact that the w3c or netvibes use it for their site should be enough to be sure about it.

But I have some points of disagreement with Mootools: I find it infatuous, too buggy for me and for a large part uselesss or even counter-productive.
Yes, this is a little proselyte _I would spend my time doing other things that writing this post if I would’nt want people to read it.
To me, Mootools is promoting itself by using a corporatist argument being “Mootools is for 31337 ; jQuery is for Noobs”.

I think this argument is bullshit. And I do not like corporatism. Real 31337 are open to the world.

You still can have good reasons to choose Mootols over jQuery (or any other framework) but please don’t fall into this gross trap.

PS: If you want to learn more on Javascript, I invite you to consult the essays and media from Douglas Crockford.

No additional note. The form just looks like any form. A long boring list of tedious to fill fields. A name that sounds good bureaucracy.
And a cheque of 143,52€ to send : …

But.. wait a minute!
Let’s look at the small bottom lines:

This mail is in fact a commercial offer. Nothing to do with any administrative obligation.
Regarding the actual interest of the service, it looks very dubious to me.

We have a nice little business here, that is playing with the auto-entrepreneuriat mood in France (a very easy way to build your own small company).

So, beware if you just registered your company.
Read the small bottom lines.

As usual, this has been a necessary pain.
As usual, the automatic upgrade failed.
As usual, my qtranslate version was said to be incompatible and I had to tweak it a little (setting it to 3.0 for me).

But, far more annoying, after I upgraded WP Super Cache, and for the second time, the visitors could only see a blank page visiting my site.

I had had the same issue on the last update and had to tweak the wp-cache source files but I was hoping that such a big thing would be corrected in the next version. Before I submit a fix to the author, here is the way I solved it on my system.

The problem was in my case that the plugin was properly caching the page, generating a nice html static file. It was also properly detecting the page had been cached on the second visit and still properly get the file name.

Then, it was doing this:

include( $cache_file );

Doesn’t tilt? Remember, the plugin had generated an html file. Including it from php just resulted in a Parse error.

So, here is my fix. just replaced the include by:

switch(array_pop(explode('.', $cache_file)))
{
	case 'php':
		include( $cache_file );
		break;
	default:
		readfile( $cache_file );
		break; 					
}

On the version I use (0.9.9.3), it is located in wp-content/plugin/wp-cache/wp-cache-phase1.php, line 212.

If you turned on crompression, the code located just above is probably faulty too.

Of course, the fix is not nice either as I should not rely on the file extension to detect its type but I am lazy (and a bit sick).
A nicer way would be to ensure that everything is cached is in a proper php format and keep the include method. (meaning, adding “?>” and “<?php” respectively at the top and bottom of the html files.

Subscribing to the KeyPressEvent is not enough.
Using AddEvent to add the KeyPress event is not enough either.

Actually, to be able to fire the KeyPress event, your widget, like a Winform Control, needs to receive focus.

So, I set the CanFocus property to true and… it does not work!
Arhgle!….

Thanks to this link, I finally got all the requirements:

• You need to use the AddEvent method to add the KeyPress event to your widget’s event list
• You need to set the CanFocus to true
• You need to subscribe to the FocusIn event and set the HasFocus property to true when it is fired
• You need to subscribe to the FocusOut event and set the HasFocus property to false when it is fired
• On the event you’d like the widget to receive focus (probably ButtonPress), you need to call the GrabFocus method

Then only you will be able to get the event.

I you have, you know it was tedious and needed quite a lot of focus for an apparently basic task.

So, I put online a very basic application to help you doing it. It does exactly this:

1. Upload your photo
2. Mark the items you want to count by clicking them

That’s it. The script will count the marks for you.

Additional tips:
You can modify the picture size by drag-dropping the bottom right handle. You can also use the “+” and “-” keys on your keyboard. The “*” key will set the picture to its original (when loaded) size.

I must admit I am still very defensive on one Agile engineering practice though: The binomial programming, promoted by the XP method. While I fully understand the big benefits of a code review, I just cannot imagine myself looking over a brother fellow’s shoulder while he is coding.

Being watched, while not very pleasant, is bearable. But the reviewer position just sounds like hell to me. Not only is he not coding, but he cannot control the rhythm of the code that is produced in front of him. Either it is going too slow and he is going to get bored and/or irritated or it is going too fast and he won’t understand and will get bored and/or irritated.

Fortunately, it looks like some alternatives do exist.