Liste des liens
"Je crois que le monde s’effondrera le jour où un poème de René Char ne pourra plus être compris sans son armada d’émoticônes, de balises et de hashtags, sans ces omniprésentes béquilles du second degré de l’explicitation, lequel n’aurait jamais dû se trouver en situation d’effacer le premier degré de la compréhension."
Vu comment la plupart des jeunes manient la langue française, je pense qu'il ne faudra pas longtemps pour que ça arrive...
Merci pour ce retour en enfance...
Un moteur de recherche libre et décentralisé qui fonctionne grâce à des DHT en peer-to-peer.
L'inconvénient, c'est que c'est du java...
Houlà : les hôpitaux fabriqueraient des psychopathes et des criminels ????
(voir http://lehollandaisvolant.net/index.php?mode=links&id=20140907081904)
Un lecteur de playlists Youtube (et consort). En vanilla js.
Cela fait un grand moment que j'utilise Sublime Text, éditeur génial s'il en est, mais je n'avais jamais trouvé comment déplacer un fichier dans un dossier.
En fait, comme souvent, c'est tout simple et il ne faut pas chercher midi à quatorze heures : il suffit de renommer le fichier !
Si vous voulez le déplacer d'un cran (c'est à dire le sortir d'un dossier), il suffit de le renommer en ajoutant "../" devant le nom du fichier : si le fichier s'appelle "file.txt", il suffit donc de le renommer "../file.txt"
Si vous souhaitez le placer dans un dossier existant (important sinon le renommage échouera), il suffit d'ajouter le chemin vers le dossier en question, avant le nom du fichier : ainsi "file.txt" renommé en "folder/file.txt" sera déplacé dans le dossier "folder", si le fichier était au préalable à la racine du projet ouvert.
Vous avez surement compris le principe. Je vous laisse tester par vous-même.
Perso, j'aurai préféré l'inverse :)
32 min quand même. Les gars qui n'ont que ça à foutre...
Un outil de drag'n drop ne nécessitant pas jQuery pour fonctionner.
Me semble plutôt pas mal.
Edit : bon ok, c'est pas un projet récent (Seb Sauvage en parlait en 2013), mais bon, je l'ai trouvé tout seul :)
Et il y a même des alternatives (Bronco, Timo...) peut-être plus légères.
Un captcha lisible par un humain. À tester...
Pas mal comme idée sauf qu'elle n'est pas utilisée par ceux qui l'ont créée !!! :)
Tout sera anonymisé ! Quelle blague. Une fois la base de données établie, elle viendra s'ajouter à celle déjà existante. Un nom ne sera plus nécessaire pour déterminer le profil d'un "utilisateur" (c'est déjà le cas) et la vente des infos aux différentes assurances n'en sera que plus facile.
Google n'est pas le Diable. C'est son coach !
"Just one more time, in the simplest terms possible:
An Interface is like a protocol. It doesn't designate the behavior of the object; it designates how your code tells that object to act. An interface would be like the English Language: defining an interface defines how your code communicates with any object implementing that interface.
An interface is always an agreement or a promise. When a class says "I implement interface Y", it is saying "I promise to have the same public methods that any object with interface Y has".
On the other hand, an Abstract Class is like a partially built class. It is much like a document with blanks to fill in. It might be using English, but that isn't as important as the fact that some of the document is already written.
An abstract class is the foundation for another object. When a class says "I extend abstract class Y", it is saying "I use some methods or properties already defined in this other class named Y".
So, consider the following PHP:
<?php
class X implements Y { } // this is saying that "X" agrees to speak language "Y" with your code.
class X extends Y { } // this is saying that "X" is going to complete the partial class "Y".
?>
You would have your class implement a particular interface if you were distributing a class to be used by other people. The interface is an agreement to have a specific set of public methods for your class.
You would have your class extend an abstract class if you (or someone else) wrote a class that already had some methods written that you want to use in your new class.
These concepts, while easy to confuse, are specifically different and distinct. For all intents and purposes, if you're the only user of any of your classes, you don't need to implement interfaces."
Quelques précisions supplémentaires et l'explication de la différence entre abstraction et interface.
"It seems like many contributors are missing the point of using an INTERFACE. An INTERFACE is not specifically provided for abstraction. That's what a CLASS is used for. Most examples in this article of interfaces could be achieved just as easily using just classes alone.
An INTERFACE is provided so you can describe a set of functions and then hide the final implementation of those functions in an implementing class. This allows you to change the IMPLEMENTATION of those functions without changing how you use it.
For example: I have a database. I want to write a class that accesses the data in my database. I define an interface like this:
interface Database {
function listOrders();
function addOrder();
function removeOrder();
...
}
Then let's say we start out using a MySQL database. So we write a class to access the MySQL database:
class MySqlDatabase implements Database {
function listOrders() {...
}
we write these methods as needed to get to the MySQL database tables. Then you can write your controller to use the interface as such:
$database = new MySqlDatabase();
foreach ($database->listOrders() as $order) {
Then let's say we decide to migrate to an Oracle database. We could write another class to get to the Oracle database as such:
class OracleDatabase implements Database {
public function listOrders() {...
}
Then - to switch our application to use the Oracle database instead of the MySQL database we only have to change ONE LINE of code:
$database = new OracleDatabase();
all other lines of code, such as:
foreach ($database->listOrders() as $order) {
will remain unchanged. The point is - the INTERFACE describes the methods that we need to access our database. It does NOT describe in any way HOW we achieve that. That's what the IMPLEMENTing class does. We can IMPLEMENT this interface as many times as we need in as many different ways as we need. We can then switch between implementations of the interface without impact to our code because the interface defines how we will use it regardless of how it actually works."
ET :
"When should you use interfaces? What are they good for?
Here are two examples.
- Interfaces are an excellent way to implement reusability.
You can create a general interface for a number of situations
(such as a save to/load from disk interface.) You can then
implement the interface in a variety of different ways (e.g. for
formats such as tab delimited ASCII, XML and a database.)
You can write code that asks the object to "save itself to
disk" without having to worry what that means for the object
in question. One object might save itself to the database,
another to an XML and you can change this behavior over
time without having to rewrite the calling code.
This allows you to write reusable calling code that can work
for any number of different objects -- you don't need to know
what kind of object it is, as long as it obeys the common
interface.
- Interfaces can also promote gradual evolution. On a
recent project I had some very complicated work to do and I
didn't know how to implement it. I could think of a "basic"
implementation but I knew I would have to change it later.
So I created interfaces in each of these cases, and created
at least one "basic" implementation of the interface that
was "good enough for now" even though I knew it would have
to change later.
When I came back to make the changes, I was able to create
some new implementations of these interfaces that added the
extra features I needed. Some of my classes still used
the "basic" implementations, but others needed the
specialized ones. I was able to add the new features to the
objects themselves without rewriting the calling code in most
cases. It was easy to evolve my code in this way because
the changes were mostly isolated -- they didn't spread all
over the place like you might expect."
Enfin, je comprends à quoi sert une interface (Merci à dlovell2001 at yahoo dot com et erik dot zoltan at msn dot com) ! Je n'avais jamais lu les commentaires associés à cette page. J'aurais dû le faire plus tôt.
Moralité : TOUJOURS LIRE LES COMMENTAIRES DES PAGES DE LA DOCUMENTATION PHP !